Re: dnssec discussion today at noon

[Derek Atkins <warlord@MIT.EDU>]

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

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

I admit that I did not count ephemeral keys in the count, but that's
because they ARE ephemeral.  There is no _storage_ of those keys in
the system.  They are created (and destroyed) in near-real-time.  My
key-count is for long-term key storage, in which case my numbers are
accurate.

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

You do not need to _store_ N-squared keys, you only need to store N
keys (one key per entity.  Yes, you need to store state during the
transaction processing (which may include an ephemeral session key)
but then you throw that key away when the transaction is complete.

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

No, it is not sufficient.  The problem is that you cannot have a
long-term store-and-forward mechanism with secret-key technology.  If
Alice wants to send a secure message to Bob using secret-key
encryption there is no way that Bob can prove to Charlie that Alice
sent the message without revealing their own secret key.  In other
words, you cannot have non-repudiation with secret-key protocols, but
this feature is ABSOLUTELY necessary for financial transactions.  If
Alice can repudiate their message to Bob, then how is Bob supposed to
collect his money?

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

Negative.  You want a key between A and D in order to maintain
confidentiality of the transaction.  Moreover, you may need to tie the
transaction to some other data (for example, I want to buy a widget
for this e-money), which implies you need a secure channel to bind the
widget to the payment.  Again, you need a key shared between A and D.

> It is also pobbible to let banks act as KDCs.

This does not work, as I previously stated.  The way the transaction
works is that A sends a token to B; B presents the token to D; D
presents the token back to C.  You cannot do that with secret-key
tokens.  If A, B, C, and D are all online together, there are
alternate protocols you can use, but it violates this particular
transaction model (which is how the current banking system is
implemented).

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

You seem to be under the mistaken impression that credit cards are the
only financial model in use.  They are not.  Cash uses a very
different "protocol", some of which may be pseudo-offline.  Moreover,
in electronic transactions the customer may want to have a GOOD IDEA
that they are talking to the "right" merchant (or at least the _same_
merchant that they were talking to yesterday).  The only way to do
this in a scalable way is Certificates.

As much as I would love to seee Kerberos take over the world, it is
not going to do so.  Moreover, with data like DNS, you cannot use
Kerberos because of the caching problem (see my previous statement
about store-and-forward data not working with secret key).

> Weak protection by HTTPS does not essentially add anything.

It adds confidentiality of your payment token, and it provides
a binding between the payment token and the paid-for object.

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

Sure.  Find me after DNSEXT.  I can show you that no matter what you
do, without cryptographic protection there is nothing you can do to
prevent me from poisioning your cache if I can get between you and the
DNS server you are querying.

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

It may be uninteresting to you, but not to many people sitting in this
room.  Skipping a topic just because you find it uninteresting is
the wrong answer.  Feel free to leave the room if you are bored.
Being here _is_ optional.

> 							Masataka Ohta

-derek

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