[dd] Challenges with DELEG awareness in DNSKEY

[Bob Halley <[e-mail]>]

Disclaimer:  I like DELEG, and am not trying to bash it nor am I
against its adoption.  This document is solely considering
specification and operational problems I’ve encountered while thinking
about DELEG.  I don’t think any of the issues are showstoppers, but I
do think further consideration is warranted.

If a validating resolver receives a delegation response from a secure
zone that has neither a DELEG nor a proof that there is no DELEG, then
either the authority is not DELEG-aware, or an adversary has removed
the DELEG, possibly to downgrade communications with the delegated
zone’s nameservers (e.g. queries will be sent in the clear instead of
over DoT/DoH/DoH3/DoQ).

To remediate this issue, the draft allocates a DELEG flag in the
DNSKEY to indicate that the server is DELEG-aware and that any
delegation will either provide a DELEG RRset or provide proof that
there is no DELEG RRset.

There are some specification and operational problems with this approach.

1) The draft talks about “the DNSKEY record” but the DNSKEY RRset of
an authority may contain many keys.  There may be KSKs and ZSKs, keys
being published as part of key rollovers, emergency keys, support for
multiple algorithms, etc.   There is also no clear notion (from the
resolver’s point of view) as to which keys are “the active keys” and
which are not simply by inspecting the RRset.  Resolvers see a signer
name, an algorithm, and a key tag on a signature, and look for a
compatible key that validates the signature. What then is the proper
awareness signal?  That any key has the DELEG flag?  That all  keys
have the valid flag?  Is it the key(s) used to sign the DS if there is
a DS RRset?  Is it the key(s) used in the proof that there is no DS
when NSEC3 OPT-OUT is in use?  Is it the KSK at the end of a proof
chain? What if there are multiple signatures, some by a DELEG DNSKEY
and some not?  Also note that DNSSEC does not require that the same
key be used in an entire proof chain.  In a negative proof with
multiple NSEC/NSEC3 it is legal to use a different key for each part
of the signature (granted this is weird and improbable).

2) If the signal is not derived from the key of some particular
signature, then all servers for the parent must be DELEG-aware before
DELEG can be used to delegate, as in that case some “all or any” type
rule must be used, and answers from the non-aware servers will not
comply as they will not emit DELEG nor will they emit the appropriate
negative proof where there is a DS. This is not necessarily a bad
thing, but it's important to realize it's a consequence.
Unfortunately, neither the “all” or “any” approaches are very
appealing due to the lifecycle issues in the next point.

3) Validation of the zone by DELEG-aware recursors is tied to the key
lifecycle.  If you want to upgrade a server to be DELEG-aware in the
future, then you can’t do the DNSKEY transition at the same time if
using the "any" or "all" modes. The server would have to become DELEG
aware first, and then transition to showing the DELEG awareness
indication with a rollover, as otherwise it signals awareness too
early. In the derived-from-signature method, you can prepublish the
key and transition atomically.

More seriously, transition from DELEG-aware to DELEG-non-aware,
perhaps to deal with a serious software bug, requires a key rollover
before dropping DELEG awareness no matter what the signaling scheme,
as otherwise the DNSKEY DELEG flag will cause DELEG-aware resolvers to
fail to validate when neither a DELEG nor the required negative proof
are included in a secure delegation.  If the awareness signal is in
the KSK, not the ZSKs, this involves a potentially devastating KSK
rollover where the zone is down for whatever TTL the authority’s
parent zone imposes (often a day or more for TLDs).

4) Extra care is needed in “multi-operator” setups when DNSSEC is
involved.  E.g. if a registrant uses authorities from multiple
operators to publish the data, then all the operators need to have
DELEG awareness (or not) and transitions from one awareness state to
another need to be carefully coordinated.


Preliminary conclusions:

* The awareness signal SHOULD NOT be in the KSK (or, more generally,
not in the records published in the authority’s parent, for the case
where the authority is not splitting the KSK and ZSK roles).

* If the awareness signal is in the DNSKEY RRset, it should probably
be in the key used to either sign the DS or in the most-enclosing part
of the nonexistence proof for the DS and DELEG types.

* Tying the awareness signal to the DNSKEY RRset imposes lower bounds
on recovery times when going from aware to non-aware as you first have
to turn off the awareness signal, then you have to disable DELEG.  Bad
data can be around for the TTL of the DNSKEY RRset plus the TTL of the
DELEG set in this case.

* Tying the awareness signal to the DNSKEY RRset imposes greater
operational complexity as it’s not as simple as adding/removing a
DELEG record at the delegation point.

* For greater simplicity, DELEG rollouts for a zone should only happen
when all authorities for the zone are DELEG-aware.

* Multi-operator DNS setups need careful coordination.

Most of what I’ve raised can be dealt with by being careful, though it
seems a little scary.  Some other possible mitigations:

Do not use an awareness flag in the DNSKEY RRset.  Resolvers can
explicitly probe for DELEG and a secure server will have to prove that
the type doesn’t exist in addition to delegating.  This is simple, and
resolvers already can have to do similar probes for DS in some cases.
It is pretty suboptimal though, as in the early days a DELEG-aware
server will make a lot of DELEG queries increasing resolution latency.
Whether this really matters is debatable however, as caching and
prefetching mean ordinary clients are not likely to experience latency
from this unless the resolver has just restarted.

Hackishly encode the awareness signal in the DS RRset at the
delegation point, e.g. with a 0 tag and a special DELEG algorithm.
The hash algorithm and hash fields would be available for other uses.
The advantage here is that the DS will be included whether aware or
unaware, and resolvers are already prepared to look for it when
needed.  Another advantage is that it allows awareness to be turned on
and off per delegated zone; this is a small thing but useful if
something in the subdomain's world might choke on the DELEG bit in a
DNSKEY, even though it shouldn’t!  The drawback here is the
duplication of the awareness signal in every secure delegation,
wasting space in the presumably common case where the authority is
aware for all delegations.  Personally I would not exploit this
per-zone capability as I think the complexity to benefit tradeoff is
not good, but I mentioned it for completeness.

/Bob