Re: dnssec discussion today at noon

[Derek Atkins <warlord@MIT.EDU>]

Unfortunately you are incorrect.

Public Key Cryptography is absolutely necessary for any
store-and-forward protocol.  Note that I said PKC, not PKI.  The _I_
part (infrastructure) is not necessary in many cases, but the
technology of public key most certainly is.  The problem is that the
alternative, secret-key cryptography, requires each pair of
communicating parties to share a key, resulting in N-squared keys in
the system.  OTOH, with public keys you only need N key-pairs in the
system (each entity has only one key-pair).

Note that the use of public-key cryptography is completely orthogonal
to the issue of transactions or money transfer that you seem to be
bringing into the picture.  I would purport that without public key
cryptography you could have ZERO financial transactions on the
Internet exactly because you could not secure them.  As an example,
look at HTTPS (SSL/TLS) -- without Public Key, SSL would not work.

So, where does DNS and DNSSec fit into this?

First, there is a strong goal to protect the DNS infrastructure.  I
wont go into the numerous types of attacks possible against DNS (feel
free to contact me personally if you really want to go down that
rathole).  Suffice it to say that various cache poisoning and spoofing
attacks can lead users and applications to contact the wrong server
site.

Second, some people believe that, once you have a secured DNS, you
could use it to deliver Public Keys.  You may not believe in Public
Key, but this is not the forum to debate that issue.

Thanks,

-derek

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> writes:

> > > There will be a hastily-organized, informal gathering to talk about 
> > > where DNSSEC is (now that we see implementations of the DS record) 
> > > and is going.
> > 
> > by the way, i know this will come as a surprise, but there will also
> > be an actual wg meeting of dnsext, where this subject will be covered.
> > :-)
> 
> To stimulate (or cool down?) the discussion, here is a theory on
> why DNSSEC (or public key cryptography as a whole) is unimportant.
> 
> Basically, public key cryptography is unimportant because the trusted
> third party (CA) is an intelligent intermediate entity.
> 
> That is, CA, the trusted third party, do not have much information on
> the first and second parties. Nor can it firmly control transactions.
> 
> With public key cryptography, in its simplest form, communication
> with CA is not necessary for every transaction. But it is so, only
> because the trusted third party knows or controls nothing about the
> transaction.
> 
> However, for real security, it is essential that there must be
> compensation for a failed transaction by a party responsible for
> the failure.
> 
> Knowing nothing about the contents of transactions, CAs can not
> be responsible.
> 
> In the real world, secure transaction consists of a chain of
> credentials between the trusted first and second parties,
> in which case, it is possible to identify on which part of
> the chain a transaction failes.
> 
> If A send B some amount of money using banks C and D, there
> is a chain of three credentials between A and C, between C
> and D and between B and D.
> 
> If A buy something from B using credit card companies C and D,
> there is a chain of three credentials between A and C, between
> C and D and between B and D.
> 
> To complete a transaction, there must be a communication between
> all the pairs of the trusted first and second parties.
> 
> Considering that we have the Internet, which connects all the
> related first and second parties mostly in real time, it is
> not a problem.
> 
> And, when there is a credential between the first and second parties,
> they can share a secret information (password, PIN etc.) to secure
> transaction, which is why public key is not necessary.
> 
> As usual with protocols violating the end to end principle,
> there is a lot of attempot to make the protocol complex to
> let CA, the intelligent intermediate entity, partially control
> the transaction.
> 
> But, as we know, such attempts are assurred to be incomplete
> and unusable.
> 
> For example, it is possible to set a upper limit on the amount
> of money carried by a transaction. But, it is not effective
> against repeated transactions.
> 
> This is why, with transactions using credit card in the real
> world, authorizations are required on all the transactions
> (except for buying, say, fresh food, too much repetition of
> which will harm the attacker by increasing his weight) even
> if there is a upper limit on each transaction.
> 
> Another interesting obserbasion is CRL. There is no expiration
> period universally applicable to all the types of transactions,
> CA may set a duration to expire a certificate and, in addition,
> may issue CRL to invalidate it quicker, which is an incomplete
> attempt of control. It is interesting that, with CRL, the trusted
> third party must be contacted quite frequently.
> 
> Finally, there is a very convincing reasoning against PKI. That
> is, "it's OSI".
> 
> 						Masataka Ohta
> 
> PS
> 
> As public key cryptography is unimportant, CAs with web browsers
> are already overkill and we don't need DNSSEC.
> 
> We can live with the weak security, security level of which is,
> with proper 3 way handshaking with cookies, equivalent to that
> of the telephone network.
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available