To:
Brad Knowles <brad.knowles@skynet.be>
CC:
Edward Lewis <edlewis@arin.net>, Markus Stumpf <maex-lists-dns-ietf-dnsop@Space.Net>, dnsop@cafax.se
From:
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date:
Wed, 23 Oct 2002 23:28:10 +0859 ()
In-Reply-To:
<a05200508b9d237682062@[146.106.12.76]> from Brad Knowles at "Oct15, 2002 11:34:02 pm"
Sender:
owner-dnsop@cafax.se
Subject:
Re: Interim signing of the root zone.
Brad Knowles; > > That's why shared key cryptography, which limits the impact of > > compromized security to the small set, members of which are directly > > involved in the action, is the way to go. > > Regardless of the encryption method, you still need a key > infrastructure. That is the fundamental misunderstanding on PKI or KI. The real world does not need PKI. People pay with credit card, not because of PKI, but because credit card campanies give credentials to their customers. > Shared-key is proven to be "secure" as an inverse > power of the number of people who have the key. Huh? Shared key cryptography with long and random enough keys is simply secure regardless of the number of the users. That's all. > This simply is not > practical on a large-scale public network. Like it or not, > public-key is the only choice we have. Your argument should be that, public key cryptography is insecure because it relies on the security of transactions of shared key cryptography which is '"secure" as an inverse power of the numer of' transactions which have the shared keys exchanged through PKI for so may transactions, > > On the other hand, the impact of compromized CAs or compromized > > employees of CAs is unlimited. > > Yup. > > > The US Gov't has this problem, too. They have devices called > "STUs", which stands for Secure Telephone Unit (last I saw, they were > up to STU-III). The STUs can be manufactured in many facilities > around the world (including Norway), but once an encryption key has > been applied to them, they become export restricted and cannot be > returned for repairs to most of the facilities where they were > manufactured. > > These keys are coordinated through a Key Distribution Center. > The Russians (and others) have shown extreme interest in compromising > the KDC, and they have been known to be successful on at least one > occasion in the past. One good compromise of the KDC (or any other > kind of CA), and you can have access to hundreds, thousands, > millions, or possibly even billions of keys. With these kinds of > stakes, people are literally willing to risk their lives, because the > consequence of getting caught is to be prosecuted for High Treason. > > A sufficiently motivated attacker can break any security anywhere. > > > CRLs and PKI are hard. I would like to see you wave a magic wand > and come up with a real solution for the problem. I don't see "web > of trust" doing us much good here. Fortunately, in the real world, no one needs PKI. Over the real world Internet, people are already paying on line with credit cards, because credit card companies are giving credential to their users through the direct relationships between the credit card companies and the users. The basic requirement is that the credit card companies reduce the amount of remaining credential on the users on every transaction. You can't use your credit card for your shopping, if the shop you are paying for can not communicate with a credit card company to authorize your credential information, for which PKI is useless. That is, that PKI reduces the need for realtime communication is just a fallacy. Moreover, best effort communication over the Internet is basically free that no one really want to reduce the need for the realtime communication. On the other hand, credit card companies or any other entities are giving credential to their users through direct relationships between the entities and the users. They can exchange and are already exchanging shared keys through the direct relatiohships. Nothing is different on (in)secure DNS that there is no point on signing the root zone. The real world does not need PKI nor secure DNS. Masataka Ohta #---------------------------------------------------------------------- # To unsubscripbe, send a message to <dnsop-request@cafax.se>.