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.