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


To: dee3@torque.pothole.com (Donald E. Eastlake 3rd)
Cc: dnsop@cafax.se
From: Dan Massey <masseyd@starlite.cs.ucla.edu>
Date: Wed, 3 Nov 1999 06:25:18 -0800 (PST)
In-Reply-To: <199911031325.IAA05710@torque.pothole.com> from "Donald E. Eastlake 3rd" at Nov 3, 99 08:25:48 am
Sender: owner-dnsop@cafax.se
Subject: Re: A conflict in algorithms (namedroppers)

null keys and multiple algorithms have caused a lot of confusion for us
in deploying dnssec on cairn so i'm very glad to see this thread.

Donald E. Eastlake 3rd writes:
> 
> Originally, DNSSEC was designed with just RSA in mind, although there
> were provisions for other algorithms.  When the IESG mandated adding
> DSA, the simplest idea was to just think of there being two
> differently secured DNS trees, one secured by RSA and one by DSA.  But
> that's really simplistic.  In particular, if many resolvers are going
> to support multiple algorithms and various zones are going to be
> signed variously with one, the other, or multiple algorithms, then it
> seems reasonable that a resolver with both algorithms implemented
> should be able to go down from an RSA only secured zone to a DSA only
> secured sub-zone to an RSA only secured sub-sub-zone, etc.
> 

in general i agree that this should be possible to switch algorithms
as you move down the tree, but i think you have to be careful in what 
security really means in this case.  taking your example, suppose you 
have the following: 

c = RSA key only
b.c = DSA key only
a.b.c = RSA key only

a resolver starts with the RSA key for c and wants to authenticate a response
from a.b.c using RSA.  using the RSA key from c, the resolver can learn
the DSA key for b.c.  using the DSA key for b.c, the resolver can learn
the RSA key for a.b.c.  finally using the a.b.c RSA key, the resolver 
authenticates the data record.  this seems to be a reasonable thing to do.

but we also don't want to say this is an "RSA authenticated" result.  note
that above example depended on DSA to get the final result.  suppose 
someone has found a vulnerability in DSA.  the attacker can use this DSA 
vulnerability to forge a false RSA public key for a.b.c.  the attacker can 
then send false a.b.c records (which will of course be authenticated by
the false RSA key).  to say the above answer has the security properties
of the RSA algorithm is incorrect. 

in this case it seems like we would like an RSA SIG record that covers
the keys for a.b.c.  one possiblity is to have c to sign the zone keys
for a.b.c since c is the nearest "parent" with an RSA key...  in a
related question, who signs a.b.c keys if b.c has no keys at all?

admittedly this is somewhat academic for RSA/DSA example, but i think it 
raises the general point about the interaction between algorithms.  


Home | Date list | Subject list