Re: dnssec discussion today at noon

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

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