RE: Interim signing of the root zone.

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

> > Note too that with CRL's, the incident above was easily rectified - 
> > in applications that fully implemented X.509 processing.
> 
> Unfortunately for you, CRL is another example on why CA-based security
> is useless.
> 
> Namely, there is no proper period to check CRL.
> 
> CAs, the intelligent intermediate systems having no knowledge on the
> requirement of applications, set the period, which is inappropriate
> for most applications.

There's nothing preventing an application checking very very often--
but a CA might not update a CRL in a timely manner.  That's one of
the reasons for OCSP responders.  But this is way off topic for this
mailing list, so let's stick to the non-CA, non-X.509 methods that are
actually going to be *used* in DNSSEC.

> > >What Masataka Ohta IMHO tries to say is that it is at best nice to
> > >have a signed root zone, but you will not gain /any/ 
> > >increase in security.
> > 
> > The goal of security is to limit the damage of an (unauthorized) 
> > action. (With "damage" being inherently "bad stuff.")  Significant 
> > subgoals of security are to lower the chance (probability) that an 
> > unauthorized action will have any impact, limiting the impact to a 
> > small set of assets, and limiting the duration of the impact.
> 
> 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.

You simply must be missing something in the last several years of
discussions, and in the history of cryptography.  Use of a symmetric/
shared/secret key algorithm might be appropriate for systems/organizations
with a pre-existing relationship--and in fact that's why such a scheme
is being used for TSIG.  But the key management problems of a symmetric
algorithm increase significantly when more one-to-one "conversation"
keys are needed, and if a single key is shared by a large cryptonet
then any compromise of one system compromises the entire cryptonet.
There's also the problem of establishing a shared key in advance.
Perhaps you live in a world where the only people whom you need to
communicate with are those with whom you've already established a
secure/authenticated communications link to support key exchange.
I'm intimately familiar with the pain involved in managing keys
for a world-wide cryptosystem using a set of shared symmetric keys,
including rollover, prepositioning, compromise recovery, etc.
Are you?

For the problem of "I need to be able to verify, when pulling data
from a DNS cache at point C, that it was authentic when it left the
authoritative server at point A and hasn't been changed since", there's
just no realistic way to use a symmetric algorithm.  There are several
severe issues related to key management--not that key management in
the DNSSEC signed zone world will be trivial, but it will be possible.
As soon as a symmetric cryptosystem comes into play, we would need to
trust all the points that might have handled the info between A and
C.
 
> On the other hand, the impact of compromized CAs or compromized
> employees of CAs is unlimited.

As I said, I'm not going to discuss X.509 anymore on a DNS list.
If each zone maintains its own zone signing key, then the closest thing
to "CAs" in the DNSSEC signed zone scheme is the upper level domains,
since a compromise of their keys could allow an attacker to falsify
records at lower levels.

But all we're doing is adding another layer of difficulty to the
attacker's problem.  If you can't trust your higher-level domains,
then it's game over *today* and you obviously can't trust them in the
+DNSSEC case.  If we assume for the moment that higher-level domains
have some existing level of trust, then DNSSEC would seem to be a
reasonable additional precaution to take--not to protect against
an insider threat within a registrar/registry, but to protect against
an external attacker.

> > Signing the root zone means that not only will the attacker need to 
> > convince resolvers that it is the true source of the root, but the 
> > attacker will also need to be able to forge the signatures. 
  [...]
> 
> It's much easier and secure to prevent forged route to the current
> UNICAST root servers and to catch the attacker.

Hmm.  How about we assume for the moment that there are attacks which
DNSSEC signed zones will provide protection against other than simply
forging routes to the root servers?  And given that there would seem
to be some good reasons to go to anycast roots, DNSSEC signed zones
seem that much more necessary to me.  Not sure why you feel that the
best answer is to stick with unicast roots and no DNSSEC.

> > There are no network police, but there are existing legal 
> > jurisdictions.
> 
> Existing legal jurisdictions is powerful enough to discourage
> forged route to the current UNICAST root servers.
> 
> > My point here is - if 
> > the attacker is thrown in jail, the attack will stop by then.
> 
> Exactly.
> 
> > PS - the roots can limit damage through a key change and proper 
> > dissemination of this.  This is a rougher thing to 
> accomplish and the 
> > attacker might get away with things for a while, but it is a help.
> 
> Certainly.
> 
> If the attack occurs 1,000 times a second and the roots act within an
> hour, the damage can be limited below that of 3,600,000 transactions,
> each of which may worth zillions of dollars.
Anyone who performs any transaction worth "zillions of dollars" based
only on DNS today is an idiot.  Anyone who performs any transaction worth
"zillions of dollars" based only on (DNS+DNSSEC signed zones) at some
point in the future is an idiot.  What's your point?  As one part of
a set of security features, DNSSEC signed zones have a place--which is
in no way meant to imply that SSL/TLS, or any other authentication/
authorization scheme, will suddenly be useless.

If we provide a useful security feature that helps address some basic
weaknesses in the protocol, and it's added in such a way that the
protocol remains as simple as possible (but no simpler), and no one
holds a gun to your head and forces you to use it, and no one's been
able to dream up a better solution which is realistic to deploy in
less than *another* five years, then what praytell is your basis for
objection?

DNSSEC signed zones do not correspond to risk avoidance--we're talking
about risk reduction/mitigation.  I continue to believe that DNSSEC
signed zones will, as soon as they are fielded, begin to reduce the
overall risk for DNS users.

Very Respectfully,
--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.