Re: dnssec discussion today at noon

[Mark.Andrews@isc.org]

> > > 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.

	And what does this have to do with DNSSEC?

	DNSSEC is designed to allow you to verify that the data you
	receive from the DNS is that which was entered.  That your
	transactions havn't been spoofed.

	What you do with that data is outside the scope of DNSSEC
	as is should a particular entity have been delegated a
	particular name.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org