Subject: Re: dnssec discussion today at noon

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Jul 2002 00:15:15 +0859 ()

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Jul 2002 05:05:41 +0859 ()

Brad;

> 	They are subject to replay attacks.

PAP is, CHAP is not.

> 	If you're talking about cryptography or computer security and you 
> don't know who Schneier is, then you don't know anything useful about 
> cryptography or computer security.

See above.

> 	There is nothing in the field of cryptography that can begin to 
> compare with a properly implemented one-time pad.  This is a known 
> fact.

:-)

You should really read text books.

In addition, you should know that cache poisoning of DNS is
prevented simply by having separate cache for each referral
point, which has nothing to do with cryptography but can be
understood with basic knowledge on computer security.

> 	Who needs civil law?  Go after them as they did with Eugene 
> Kashpureff, and put the sucker in jail!

It is clearly stated in their contract that operators of CAs won't
compensate much.

It is obvious that people here who operate root and tld servers
won't compensate much.

We can not be responsible for the stupidity of someone who use
DNSSEC to secure billion dollar transactions.

Civil laws will treat those who think they secured billion
dollar transactions, simply because they pay $100 treat
accordingly.

							Masataka Ohta

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Jul 2002 10:14:46 -0700

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

I am not too sure that Bruce made quite the point originally stated,
and if he did make it one should take a look at some other statements
Bruce has been known to state before necessarily taking his word as
gospel.

In fact I would suspect that a more accurate representation of
Bruce's position would be 'think about the protocol, don't depend
on dogma, including dogma that you might find attributed to me.'

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 22 Jul 2002 13:22:06 -0700

> You have clearly never been to an hotel where their Internet services
> intercept all DNS queries regardless of where you send the message...
> You cannot trust the infrastructure not to misbehave.  

Answer, I tend not to pay $10 per night just to surf the Internet
from a hotel room and when I have I have been using a VPN which 
encrypts all the trafic.

Question, what do you want the infrastructure to do in this 
situation? I believe that what a secure DNS infrastructure should
do is inform you that you are subject to a DNS MiM attack.

If you are going to use secure DNS then you probably want to 
use IPSEC to protect you trafic from hotel rooms and the like.
If the institution blocks IPSEC then you should probably apply
Moscow rules and not use the Internet at all.

		Phill