[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Brad Knowles <brad.knowles@skynet.be>
Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se
From: Brad Knowles <brad.knowles@skynet.be>
Date: Wed, 17 Jul 2002 12:22:59 +0200
In-Reply-To: <200207170131.KAA06741@necom830.hpcl.titech.ac.jp>
Sender: owner-dnsop@cafax.se
Subject: Re: dnssec discussion today at noon

At 10:30 AM +0859 2002/07/17, Masataka Ohta wrote:

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

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

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

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

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

>  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.  Moreover, you make damn 
sure that no one ever figures out who is "randomly" typing your 
one-time pad so that they can calculate the probability of what 
characters will be typed, and use that to help them break the message.

	Since compromise of a shared secret leads to compromise of both 
ends (or could have been the responsibility of either end), PKC is 
much preferable for everyone involved.  Or, use both shared secrets 
and PKC, to help you solve different parts of the problem.


	Note that PKC doesn't necessarily depend on any CA structure or 
any other PKI structure.  That's just the implementation detail you 
are imposing as a straw man, which you can then knock down and claim 
to prove the PKC is inherently unsuitable.

	We've seen this method of argument before, and we know how to deal with it.

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

>  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.  Shall I now go pollute the cache of 
dns0.spin.ad.jp, and direct all traffic for titech.ac.jp over to some 
bukake site?

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

Home | Date list | Subject list