A conflict in algorithms (dnsop)

[Edward Lewis <lewis@tislabs.com>]

This is separately posted to both dnsop and namedroppers, but not
cross-posted.  If you are on both lists, please reply to dnsop on this
topic.

During the two DNSSEC workshops - one held by the NIC-SE and another by the
CAIRN research network - the most troublesome issue raised concerns
situations in which a parent zone uses different algorithms than the child
zone.

E.g., a parent zone may use both DSA and RSA to sign its zone.  One of the
delegations uses just DSA.  The child's DSA key is sent to the parent for
validation.  The parent zone could either just sign the one key with both
of its two keys, or do that plus add a NULL zone key for RSA.  The latter
is what the currently implemented code does.

Part of this issue is rooted in deciding what makes a zone signed.  Some
folks have suggested that a zone is signed if there is some zone key in
use, and the zone key is valid.  This makes sense, but is in conflict with
RFC 2535, section 3.4, which states that the security of a zone is per
algorithm.  In other words, my zone may be secure in DSA, but unsigned in
RSA.  This per algorithm sounds like splitting hairs, but this "has to be"
because of the experimental keys.

So, the parent is obligated to add a NULL key for RSA in the example above.
This raises a dilemma.  Now the parent must hold the key set of the child
(there is a NULL key), but this means that it must also hold the regular
key too.  The latter is the reason why the (mothballed) SEC record has been
proposed - to remove the need of the parent's holding of a potential
liability.

There is even a stickier situation.  What if the parent uses an algorithm
that that child does not understand?  DSA is mandatory to implement, RSA is
not, and there are "local" algorithms allowed.  The child will be seeing
SIG records it can't parse and NULL keys it may choke upon.  The latter
means the child won't ever be able to verify the parent signature on its
own keys - the former means that the child will have an unuseable SIG on
its hands.

I propose that we define a zone's security status as per zone, not
algorithm.  Further, we should drop the experimental status of a key
algorithm (maintaining experimentaly secure by zone).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.