Re: dnssec discussion today at noon

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

Brad;

> >  Are you saying that the B2B website gladly accept a billion dollar
> >  order from some unkown company just because a CA says the company's
> >  domain name is not faked?
> 
> 	Man-in-the-middle attack.  All data that flows from point A to 
> point B (or vice-versa) is legitimate.  It just happens to be 
> secretly routed through point C, whereby all traffic is sniffed, all 
> passwords are captured, etc... so that this information can be used 
> in the future to forge a real transaction.

Shared key cryptography can be a protection from the MITM attack.

If you think plain text passwords can be on the wire, you haven't
seriously considered requirements for commercial transactions.

> >  Purely techinically, if secret is shared between the website and the
> >  company, shared key cryptography protect you from a clever fake and a
> >  MITM attack.
> 
> 	This assumes perfect implementation of the cryptography and the 
> manner in which cryptography is used (and the whole rest of the 
> system).  Schneier teaches us that this is a highly unlikely 
> situation to occur anywhere.

I'm teching you Schneier (whoever he is) is wrong, then.

> >  But, it is not enough credential to perform serious commercial
> >  transaction. The website should check credit status of its
> >  members.
> 
> 	As far as the site is concerned, the account is valid, the 
> password is valid, what more do you want?  Heck, they can even 
> confirm that at least one valid transaction in the past came from the 
> same source (which the client can confirm), because there had to be 
> at least one full transaction that passed through the MITM.

I'm saying that the site and its customer must establish
credential relationship.

If a bank reliably says that a company has large amount of
cash, the company is reliable.

> >  Protection for home banking is by shared secret.
> 
> 	Yes, you use shared secrets when you log in with your account & 
> password, but the client still needs to be certain that when he asks 
> to go to www.insertyourbankhere.com (or uses the custom home banking 
> software), that this really does take them to the appropriate site in 
> question and that cache poisoning attacks cannot cause this access to 
> be directed to a different site that might then do a MITM attack.

Then, you are blindly belive CAs are secure.

Even if they were, the reality is that most clients never checks
whether the transaction use https or http.

So, it is stupid to send plain text password with https.

> >  You can't ask root server operators for compasation for billions
> >  and trillions of dollars worth of damages when someone spoofs a DNS
> >  response.
> 
> 	No, but I can hold up your name as the person who stood in the 
> way of implementing DNSSEC and DS, and therefore you would be at 
> least partially to blame for security breaches that occur anywhere in 
> the world that might have been preventable with DNSSEC and/or DS.

As you said:

>>                                       Getting DNSSEC working
>>       only requires that the operators of the root servers, down
>>       to the zone servers do the right thing.
>
>        Which is hard enough.  Witness all the incredibly screwed up TLD
>servers.  Witness the differences in the modes of operations of the
>root nameservers themselves -- do you block all zone transfers or not?

you can't identify the person to be blamed for.

Even if you can, have you ever checked standard contract of CAs? How
much is the upper limit of compensation for failed transaction?

> >  Serious users protect them with shared secret. They don't blank-mindedly
> >  rely on CAs not really offerring any serious compasation.
> 
> 	No.  If you want serious protection, you use a one-time pad, and 
> you make damn sure it never gets used again.

Have you ever heard about things called CHAP?

You don't have to send your password in plain text over the wire.

> >  And, there will be multiple screwed up CAs. Or, are there already?
> 
> 	So there are multiple screwed-up CAs.  DNSSEC and DS will be an 
> improvement over what we've got now, and we will have a smaller set 
> of problems to deal with once they are in wide use.

The more complex protocol, the larger set of problems.

> >  So, have weakly secure Internet and DNS as a infrastructure and don't
> >  rely on intermediate entities of servers, routers or CAs.
> 
> 	Which is what we have now.

Exactly. The real world is not using CAs.

							Masataka Ohta