Re: dnssec discussion today at noon

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

Derek;

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

That is a wrong counting.

First, the number of dynamically generated shared key is same,
regardless of whether you use public or shared key cryptography.

If N party directly interact with all the other N-1 parties, you need
N-squared keys regardless of whether you use public or shared key
cryptography.

Preconfigured secret-key, on the other hand, is necessary, only when
there is preconfigured credential.

By having KDC, we need as much secret key as necessary for PKI with CAs,
though KDC as the trusted third party is as bogus as CAs.

However, it is fine to have KDC as the trusted first or second party.

To send money from A to B through banks of C and D, secret keys are
necessary between A and C, C and D, D and B, but not A and D.

It is also pobbible to let banks act as KDCs.

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

Huh? What is necessary for the financial transactions is credential
between credit card owners and credit card companies.

Weak protection by HTTPS does not essentially add anything.

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

That's why it is stupid to make DNS even more complex.

Feel free to contact me personally, if you really want to know the
rathole, for example, on how easily cache poisoning can be prevented
and how wrongly various implementations tried to prevent it.

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

That is an uninteresting topic. Let's skip it.

							Masataka Ohta