Re: A conflict in algorithms (namedroppers)

["Donald E. Eastlake 3rd" <[e-mail]>]

Hi,

From:  Edward Lewis <[e-mail]>
Message-Id:  <v03130303b4205b02c565@[207.172.246.225]>
Date:  Tue, 5 Oct 1999 22:14:59 -0400
To:  [e-mail]
Cc:  [e-mail]

>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.  If you are only on namedroppers and wish not to subscribe to dnsop,
>let me know if you would like any of your related comments to be sent on to
>dnsop.
>
>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.

I think RFC 2535 has problems here.

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.

It seems to me that the way to look at whether a zone is secure or not
is from the point of view of a security aware resolver (including the
resolver part of recursive servers) willing to do its own crypto.
Such a resolver should always be doing CD (checking disabled) queries
to reduce latency so it can get data faster and do the checking
itself.  The resolver wants to give the best answers it can for
queries in the sense of the answer being either secure (validly
traceable to a staticly configured key (such as root) at the resolver)
or not secureable.  Data from an unsigned zone is not secureable.  So
is data from, say, zone a.b, even if that zone is signed, if zone .b
is unsigned and the resolver is trying to work its way down and has
only a root key staticly configured.  From the point of view of such a
resolver, it seems to me that a zone which is signed only by an
algorithm or algorithms the resolver does not understand is exactly
the same as an unsigned zone.  The best the resolver is ever going to
be able to do is just hand over RRs from the zone without crypto
checking. If its interface to the application calling it is
sufficiently rich, it should flag the data as unsecureable.

>From this point of view, and temporarily ignoring the "experimentally
secure" case, it would seem that a zone should either have one
"algorithm independent" NULL KEY saying it is unsigned or one or more
specific algorithm KEYs saying it is signed with those algorithms.
Look at it another way, sooner or later new crypto algorithms will
come along.  Say a zone is signed with RSA and DSA and algorithm XYZ
is added to DNS.  How would older software ever know to add a NULL KEY
for the XYZ algorithm?  Obviously, it wouldn't.  But since you get the
whole KEY RRSET signed, you can see for what algorithms there exists a
zone key for and which there doesn't.  So there really isn't a logical
need for a per algorithm NULL KEY...

Of course the current NULL KEY does have an algorithm and if the spec
were changed, the easiest change from the point of view of existing
implementations to get the desired effect seems best...  Perhaps
saying that a there should be either a single NULL KEY, in which the
algorithm field is ignored, or one or more non-NULL KEYs.

But the above ignores the experimentally secure case.  The idea with
experimentally secure zones is that, as a trasnition of the zone to
secure, you can have a state where if signatures are returned, they
get checked, but if not, a resolver can go ahead and provide data
saying it is unsecureable.  That way you can transition a zone from
unsecured to experimentally secure and after testing things out, go to
secure.  This is intended to minimize the risk of self inflicted
denial of service due to security problems.

Do people think this is a good idea?  Do we have enough interoperation
and deployment experience to say if the complexity is worth it?

In any case, if overall zone experimental is all you need, you could
have the choices of an insecure zone with a NULL KEY, a secure zone
with one or more non-NULL KEYs, or an experimentally secure zone with
both a NULL KEY and one or more non-NULL KEYs.  But that's probably
hard to do right now with algorithm specific NULL KEYs.  For algorithm
specific experimental, you need to have both a NULL and non-NULL KEY
for each algorithm...

>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.

The parent does not always have to hold the KEY RRSET for the child
just because there is a NULL zone KEY.

I think that it will be a while before all of DNS is secure. In
particular, if you consider something like securing .com, there are a
lot of logistic and political and financial etc. problems in suddenly
or even with some months of lead time telling every child of .com that
they must add a NULL KEY RR and SIG by .com at the apex of their zone
(or perhaps pay extra to get a real key signed).  But, for unsecured
children of a secure .com, the NULL KEY RR must be accessible
somewhere.  Until they find a KEY RR for the child of a secure parent,
security aware resolvers don't know if it is safe to return an
unsecureable answer. And the only place a resolver could know to look
at are the leaf node in a parent name server or the apex node in a
child name server.  So, if it is impractical to modify some children,
then the option of putting it in the parent must be available.  So, as
a trasnition measure, it seemed reasonalbe to require DNSSEC
implementation to support having the keys for a zone stored at the
leaf node in the parent, at least for the insecure child case.  If all
of DNS were secure, you could just say that zone keys were always at
the zone apex but the case of stogy children will be around for some
time.  What RFC 2535 says (capitalization added for emphasis) is
(section 2.3.4):

   There MUST be a zone KEY RR, signed by its superzone, for every
   subzone if the superzone is secure. This will normally appear in the
   subzone and may also be included in the superzone.  But, IN THE CASE
   OF AN UNSECURED SUBZONE WHICH CAN NOT OR WILL NOT BE MODIFIED TO ADD
   ANY SECURITY RRs, a KEY declaring the subzone to be unsecured MUST
   appear with the superzone signature in the superzone, if the
   superzone is secure.

The few times I have posted on this matter, I have tried to always
include the caveat that the requirement to support a NULL KEY held by
the parent was necessary only for and motivated by child zones for
which it was inpractical, in the short run, to add security RRs.  If
children are modifiable, say in a corporate setting where the children
are deparments or sites, and you have cohesive management, there is no
particular reason not to always put the zone KEY RRs at the child
apex, even for a NULL zone RR.

>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.

This is a sticky area.  If there is no way to set up secure
communications between a parent and a child, there is no way for the
parent to trust any KEY it got from the child for signing or the child
to trust any SIG it got as really being from the parent or valid.  In
such a case, it seems to me the parent needs to declare the child
insecure and hold a NULL KEY for it (or a NULL KEY per parent
understood algorithm under a strict interpretation of the current RFC
2535).  Meanwhile, the child, if actually signed, should include its
KEYs at its apex.  Only secure resolvers that have the child's key(s)
staticly configured will be able to produce secure answers for the
child, but that may be quite important.

If there is some way to get secure communications between the parent
and child, due to a TSIG key being set up or just one common public
key algorithm, then it should be possible for the child to securely
send its zone KEY(s) to the parent for signing and for the parent to
securely return its SIG(s) on those KEYs.  I don't see too much
problem in the child storing parent SIGs on its zone KEYs that use
algorithms it does not understand.

(By the way, there have been very few comments on on
draft-ietf-dnsind-rollover-00.txt (actually the third version, the
first two being draft-ietf-dnssec-rollover-*) by myself and Mark
Andrews.  Should the next version of that be
draft-ietf-dnsops-rollover-*?)

>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).

You're right.  That makes a lot of sense.  I think that, further, if
it is not too much of a problem for existing implementations, NULL
zone KEY RR's should specify an algorithm of zero to make their
declaration of insecurity be across all algorithms or else the spec
changed to say that the algorithm field is ignored in NULL KEYs.

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: [phone]                      Email: [e-mail]
>
>"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.

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   [phone]   [e-mail]
 65 Shindegan Hill Rd, RR#1  [phone](w)     [e-mail]
 Carmel, NY 10512 USA