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


To: "'Masataka Ohta'" <mohta@necom830.hpcl.titech.ac.jp>
Cc: dnsop@cafax.se
From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>
Date: Wed, 23 Oct 2002 12:50:26 -0400
Sender: owner-dnsop@cafax.se
Subject: RE: Interim signing of the root zone.

Masataka Ohta wrote:

> > >  That's why shared key cryptography, which limits the impact of
> > >  compromized security to the small set, members of which 
> > >  are directly involved in the action, is the way to go.
> > 
> > 	Regardless of the encryption method, you still need a key 
> > infrastructure.
> 
> That is the fundamental misunderstanding on PKI or KI.
> 
> The real world does not need PKI.
> 
> People pay with credit card, not because of PKI, but because
> credit card campanies give credentials to their customers.

I'm sorry that we seem to be going around and around in this.
Rather than continuing to try to use examples/metaphors/
similes/comparisons with non-DNS uses of cryptography, perhaps
it would be more productive to stick to DNS--which remains
the topic of this working group.  I'll diverge one more time
into trying to rehash basic principles of cryptography.  

Any cryptographic system using symmetric algorithms (and therefore
shared keys) can generally provide strong privacy for communications
between two parties--if those parties are the only ones who hold
the key used for that communication.  As soon as the number of
participants in the cryptonet expands (number of holders of the
same key) then the effectiveness of the privacy/confidentiality
decreases--because the probability of the key's compromise increases.
And for shared-key algorithms, the ability to authenticate the information 
is weak at best for any cryptosystem with more than two members--
because anyone holding the key will be able to produce a "statement"
that any other member of the cryptosystem would consider "authentic".
 
> > Shared-key is proven to be "secure" as an inverse 
> > power of the number of people who have the key.
> 
> Huh?
> 
> Shared key cryptography with long and random enough keys is simply
> secure regardless of the number of the users.

I'm sorry, you're wrong--because one assumption (when discussing
security of a cryptosystem) is that eventually a key *will* be
compromised.  And therefore, the more users in a shared-key
cryptosystem the lower the effective security.  One could, I suppose,
describe such a situation as "very secure in the short term, and
much less secure as time goes on".

If your objection is that each of the users is responsible for
protecting the key, and therefore will ensure that the key is
never compromised--I'm sorry, but the fact that someone is
responsible for protecting something doesn't mean that the something
will always be protected.  There have been (and will continue to
be) compromises of sensitive keying material for military secrets.
There are organizations who spend millions of dollars every year
trying to prevent such compromises--but they do happen.

More importantly, the "shared key" method of securing DNSSEC doesn't
scale to the thousands of cryptosystems which would be required, each
with thousands of users of a singled shared key, any better than
public/private key methods--and the public/private key methods have
the added advantage of end-to-end protection of the DNS data against
modification/spoofing--rather than the point-to-point (and unprotected
in cache) protection that would be provided by symmetric algorithms.
See below for more discussion of this point.

[...]
> Over the real world Internet, people are already paying on line with
> credit cards, because credit card companies are giving credential to
> their users through the direct relationships between the credit card
> companies and the users.
Over the real world Internet, people are already paying on line
with their credit cards because:
  - People want convenience
  - Most people have access to browsers that support SSL
  - Many vendors have servers that use SSL to protect credit cards
    in transit
  - For those vendors who don't protect credit cards adequately
    (in transit or storage) people will generally continue to order
    things but chargebacks (from the credit card issuers) will
    generally force the vendors to adopt better security measures
  - Credit card issuers generally have fairly good fraud detection
    methods in place
  - Even with chargebacks and fraud prevention, banks and credit
    card issuers still incur a loss on some fraudulent transactions--
    but they accept this loss as part of doing business (and pass
    the cost along to the consumer in the form of direct fees and
    the indirect fees charged to the vendors)

However, *none* of that matters a hill of beans on the question
of whether DNS needs DNSSEC signed zones.  Could you please
try to limit your discussion to the actual topic?  There's no
way that I, at point "C", am ever going to be able to guarantee
that I share a secret with the authoritative servers for all the
zones I want to contact ("A1" ... "A20", let's say).  I'm not
even going to be able to guarantee that I can share an acceptable
secret with every recursive server I might use on every network I
plug into, and I'm *definitely* not going to be able to guarantee
that each of those recursive servers has a secure way (using symmetric
cryptography and shared keys) to authenticate all the data coming
in from the authoritative servers.  Even if there supposedly was
a secure way, each of those shared key cryptosystems would only
protect data in transit from one point to another...*not* while
it was stored in a cache.

The *only* way we're ever going to be able to get DNSSEC signed
zones deployed is with public/private key cryptography.  You
seem to have an issue with that answer, but you just haven't
provided an adequate alternative solution in my opinion--and
"just let it go as is" doesn't work for me either.

> The basic requirement is that the credit card companies 
> reduce the amount of remaining credential on the users on
> every transaction.
That sentence does not parse--could you rephrase please?

[...]
> The real world does not need PKI nor secure DNS.

Making such a statement, with only opinions and (in my opinion)
misunderstandings to back it up, does not impress me *or*
make it true.  We're not talking about a centralized PKI, we're
talking about a distributed usage of public/private key
algorithms to provide additional security (authentication)
for DNS traffic.  And yes, I *do* (as a representative of
"the real world") need secure and reliable DNS including the
ability to authenticate that a piece of DNS data did in fact
come from the zone owner and has not been changed since.  Not
sure why you feel qualified to speak on behalf of "the real
world" to the exclusion of all others.

  --Rip
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list