Multiple Algorithm Rules in DNSSEC
Salesforce
shuque@gmail.com
deSEC, SSE
peter@desec.io
Google LLC
ietfdane@dukhovni.org
Verisign
dwessels@verisign.com
General
Internet Engineering Task Force
InternetDraft
DNS
DNSSEC
Multiple
Algorithm
Rules
This document restates the requirements on DNSSEC signing and
validation and makes small adjustments in order to allow for
more flexible handling of configurations that
advertise multiple Secure Entry Points (SEP) with different
signing algorithms via their DS record or trust anchor set.
The adjusted rules allow both for multisigner
operation and for the transfer of signed DNS zones between providers,
where the providers support disjoint DNSSEC algorithm sets.
In addition, the proposal enables prepublication of a trust
anchor in preparation for an algorithm rollover, such as of the
root zone.
This document updates RFCs 4035, 6840, and 8624.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
The Domain Name System Security Extensions (DNSSEC)
add data origin authentication
and integrity protection to the Domain Name System (DNS),
by having DNS zone owners (or their operators) crytographically
sign their zone data.
Current specifications
require that a zone be signed with each signing algorithm listed
in a zone's DS RRset or appearing via its trust anchors (TAs).
This poses a problem for (at least) the following cases:

In multisigner setups (MultiSigner
Extensions Section 2.1.2), multiple providers using
distinct DNSSEC keys can cooperatively serve the same DNS zone.
This methods does not work however if the providers
involved employ different DNSSEC algorithms.

DNSSEC Automation further
describes how to fully automate MultiSigner operations, including
how to use a transitional state of a multisigner configuration
to nondisruptively transfer a signed zone from one provider to
another. If the old and the new provider do not use the same
signing algorithms, the same problem is encountered.

When performing an algorithm rollover for a zone with a trust
anchor, current specifications mandate that the zone has to be
doublesigned with both the old and the new algorithm before
publishing the new trust anchor. For the root zone, this could
lead to a potentially rather long phase of doublesigning (on the
order of a year). As this comes with both financial and operational
risks, it seems desirable to find a way for publishing the new trust
anchor without introducing the new algorithm into the zone just yet.

Furthermore, for online signers, producing on the fly signatures
for several algorithms imposes a significant computational burden.
The above issues are not just a theoretical problem. Real situations in
the field have occurred where the existing requirements have posed an
obstacle to DNSSEC deployment and operations.
That said, the existing signing requirements
are well motivated: When a zone's DS RRset or
trust anchor set includes multiple DNSKEY algorithms, an attacker who
can strip all the supported RRSIGs from a signed response from that
zone, leaving just the unsupported signatures, must not be able to
disable validation for that zone, effectively downgrading the zone to
"insecure". The rules therefore ensure the downgrade resistance of
DNSSEC when only some, but not all, of a zone's DS RRset or trust
anchor set DNSKEY algorithms are supported by a validating resolver.
This document proposes modifications of the signing and validation rules
to accommodate additional use cases, without compromising
the security guarantees given by DNSSEC.
The heart of the issue is that even though any one acceptable signature
suffices for validation, the signer cannot, in the general case,
know which particular signing algorithm(s) the validator will support;
and hence, providing a "large enough set" (read: all of them) is the
approach that had been taken so far.
This is set down in Section 2.2 of :
There MUST be an RRSIG for each RRset using at least one DNSKEY
of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY
RRset itself MUST be signed by each algorithm appearing in the DS
RRset located at the delegating parent (if any).
In the following, two different ways of amending this existing
specification are described. Both methods advocate that
signers adopt a more liberal approach to the requirement of
signatures by algorithm sets. The minimal approach provides
cautionary advice to zone owners about the selection of
appropriate algorithm sets. The comprehensive approach more
precisely defines which algorithms are safe to use in this
way, and additionally places some of the burden on validating
resolvers to ensure this safety.
The most straightforward proposal is to relax the rule quoted from RFC
4035 by changing the MUST to a SHOULD, and state that there are valid
configurations where this rule could be disregarded.
This approach puts the burden on the zone owners/ signers to only
select suitably strong and well supported algorithms (such as
algorithms 8 and 13). It does not require any new changes to
validating resolvers  they just have to follow the clarifying
rule in RFC 6840 that any valid authentication path is acceptable.
It thus represents a minimal approach to achieving the goals
outlined in the abstract.
If zone owners do not carefully select such a set of widely
supported algorithms, this can cause problems. For example, if
they choose 7 as one of the algorithms, it may cause validators
to return SERVFAIL under certain circumstances.
More explicitly, a zone that is using such an algorithm as its sole
signing algorithm is (correctly) treated as insecure by resolvers that
do not support that algorithm. When attempting to transfer the domain
to another DNS provider through a multisigner setup with a supported
algorithm, affected resolvers will return SERVFAIL when presented with
the unsupported signature only. Zone owners and signers thus must take
great care to not leave a validating resolver without a valid
supported path when transitioning e.g. from algorithm 7 to 13.
This approach establishes a mechanism allowing the signer to determine
which RRSIGs can be skipped, without risking validation failures. It
does not require all algorithms' RRSIGs to be present, while ensuring
that the set of signatures provided is still "large enough" for
reliable DNSSEC operation, so that robust multisigner operation
and TA prepublication are made possible, without risking validation
failures.
For the case of a multisigner setup with two generally supported
algorithms (such as 8 and 13), the scheme requires only one of the two
signatures. Similarly, when prepublishing a trust anchor, associated
signatures don't need to be published immediately, provided that the
existing TA's algorithm is generally supported.
The notion of UNIVERSAL signing algorithms is introduced, and
defined as follows:

The information contained in the table of
Section 3.1 is transferred into a
tobeerected IANA registry, and a boolean column is added with
the heading "universal validation support". Signing algorithms
where this column is TRUE are called "UNIVERSAL".

"MUST validate" is a prerequisite for UNIVERSAL. Changes that
affect whether an algorithm is UNIVERSAL require standards
action.

Algorithms 8 and 13 are the only algorithms initially declared
UNIVERSAL.
Also, the notion of FORMERLY UNIVERSAL signing algorithms is
introduced:

As soon as a UNIVERSAL algorithm is known or expected to have
declining validation support, it should be moved to FORMERLY
UNIVERSAL.

Algorithms 5 and 7 are the only algorithms initially declared
FORMERLY UNIVERSAL.
[ TODO Were 1, 3, 6, 12 ever universally supported? ]

Absent any UNIVERSAL algorithms in the DS RRset or trust anchor
set, or when any FORMERLY UNIVERSAL algorithms are present,
signers MUST sign with all algorithms listed.

Otherwise, signers MUST sign with at least one UNIVERSAL algorithm
listed in the DS RRset or trust anchor set. Other signatures are
OPTIONAL.
UNIVERSAL and FORMERLY UNIVERSAL algorithms SHOULD NOT appear
together in a DS RRset or trust anchor set. In fact, FORMERLY
UNIVERSAL algorithms are best avoided: signers SHOULD transition
to other algorithms that are UNIVERSAL.

When the DS RRset or trust anchor set for a zone includes an
unsupported FORMERLY UNIVERSAL algorithm, validators MUST treat
the zone as unsigned, even if the DS RRset or trust anchor set
lists another supported algorithm.

Otherwise, validators MUST accept any valid path.
Implementing these rules requires validators to keep a record of
unsupported FORMERLY UNIVERSAL algorithms, so that the zone's security
status can be established upon inspection of a DS record or TA set.
Any UNIVERSAL algorithms that a validator supports by default but are disabled on
the validator as a matter of local policy SHOULD also be considered FORMERLY
UNIVERSAL unless explicitly configured as "unsupported". The choice
should be made with care. Disabling an algorithm to FORMERLY UNIVERSAL downgrades
zones signed with the disabled algorithm, while disabling it as "unsupported"
risks making some zones "bogus", if it was used as the only signing algorithm
by one of the signers in a multisigner, multialgorithm setup.
It is observed that validators need only to know the concept of
"FORMERLY UNIVERSAL"; knowledge of which algorithms are UNIVERSAL is
not required. This limits the implementation effort.
The new validation requirements enable stable multisigner setups
using UNIVERSAL algorithms as well as robust provider
transfers and algorithm upgrades from FORMERLY UNIVERSAL to UNIVERSAL
algorithms (such as algorithm 7 to 13), without risking SERVFAIL
responses in the event that a validator no longer supports one of
the algorithms (e.g. 7). For a detailed discussion, see
Security Considerations.
DNS operators in a multisigner setup are free to limit their
responses to serve signatures for one UNIVERSAL algorithm only.
This one signature is sufficient to provide a valid path everywhere.
When a UNIVERSAL algorithm is in use, signatures of other
algorithms are not required. DNS providers are thus free to
introduce additional algorithms (which were never UNIVERSAL) without
forcing other participating providers to do the same.
When trust anchors are in use for a zone and there is one with a
UNIVERSAL algorithm, it is permissible to introduce a new trust
anchor for a different algorithm before introducing the
corresponding DNSKEY and RRSIGs into the zone. (Of course, they
need to be added before the old trust anchor is removed.)
If the added trust anchor is also for a UNIVERSAL algorithm, it is
permissible to eventually switch to returning just the RRSIGs for
the new algorithm, without an intermediate dualsigning period. If
the new trust anchor is not yet UNIVERSAL, a dual signing period is
required in order to complete the algorithm rollover.
In typical cases, particularly in the case of the root zone, both
algorithms will be UNIVERSAL. In a hypothetical emergency situation
where only the new algorithm is UNIVERSAL and the old was just
downgraded to FORMERLY UNIVERSAL, the new signatures would need to be
introduced immediately. A short dual signing period would then be
required for continuity. Validators would be expected to defer
disabling the old algorithm until after the root zone rollover is
completed.
The minimal approach has no IANA actions.
When the comprehensive approach is taken,
this section will need to be updated to describe the construction of
the new IANA registry for the implementation status and requirements of
DNSSEC signing algorithms.
The minimal approach requires the zone owner and signer(s) to take
great care in order to not break working setups by entering a
multisigner setup. In particular, when transferring a zone to another
DNS provider and switching from e.g. algorithm 7 to 13 in the process,
resolvers that do no longer support algorithm 7 will expect a valid
path for algorithm 13. If the response only contains an RRSIG for
algorithm 7, the result will be SERVFAIL.
The minimal approach is thus only workable in cases where the
multisigner setup involves universally supported algorithms
exclusively. As the set of universally supported algorithms evolves
over time, zone owners and signers need to monitor developments and
upgrade algorithms before validation support for the involved
algorithms is declining and SERVFAIL looms.
The new validation requirements presume that zones using multiple
algorithms are either in a state of transition (e.g. when switching
providers) or in a permanent multiprovider configuration. In the
first case, if the outgoing algorithm is not supported by the
validator, the zone would have been treated as insecure before the
transition. For the second case, it is noted that the purpose of
multiprovider setups is to provide resilience against any single
provider's failure. Consequently, the zone owner is assumed to
consider the security guarantees given by any single provider to be
acceptable for the whole zone. By implication, if one of the providers
has fallen behind and is signing with an algorithm that is no longer
supported by some resolvers (and thus promises no security), there is
no guarantee of DNSSEC security for the zone.
In other words, the validation requirements guarantee that a zone in a
multiprovider setup has the same security level as if all but one of
the involved providers would be unavailable. Consequently, when the
configuration involves an algorithm that is no longer universally
supported, nonsupporting validators may treat the zone as insecure.
This resolves undue SERVFAIL issues that could occur with certain
algorithm combinations under the previous rules.
For example, a zone using only algorithm 7 is treated as insecure
by validators that do not support this algorithm. (This is as before.)
When transferring the domain to another provider via a multisigner
setup with algorithm 13, however, the zone's security status will now
remain "insecure", as the DS RRset still includes FORMERLY UNIVERSAL
algorithm 7. The presence of algorithm 13 is inconsequential at this
point. Only once algorithm 7 is removed, the zone turns secure.
This rule acknowledges the fact that the signer is using a FORMERLY
UNIVERSAL algorithm that SHOULD NOT be used for signing, which might
render the zone insecure for validators that lack support. This
prevents validation breakage when the validator encounters an
unsupported RRSIG from an outdated algorithm, and allows for
glitchfree algorithm upgrades with the security status of the zone
changing only once the transition is complete.
Validators supporting both algorithms retain security
throughtout the transition. In case of a permanent multisigner setup,
the zone maintainer needs to move from the FORMERLY UNIVERSAL
algorithm to a UNIVERSAL one in order to restore universal validation.
The same situation occurs when an algorithm is removed from the set of
UNIVERSAL algorithms. In this case, the algorithm will become FORMERLY
UNIVERSAL. If the zone continues to use the FORMERLY UNIVERSAL
algorithm, it will continue to be accepted by supporting
validators, while nonsupporting validators will treat the zone
as insecure until the algorithm is replaced.
Conversely, when an algorithm is added to the set of UNIVERSAL ones,
signers MAY begin to return signatures for just that algorithm. This
is, in fact, not a problem, as validators do not need to know the
concept of UNIVERSAL; they just need to support that algorithm (or,
typically, explicitly classify it as FORMERLY UNIVERSAL). A problem could only
occur if the corresponding RRSIG was not supported by a nonnegligible
population of validators; however, in that case labeling the algorithm
as UNIVERSAL would have been premature. Determining universal support
cannot be solved on the protocol level, and it is the community's
responsibility to only advance an algorithm to UNIVERSAL when safe
enough, i.e. when the population of validators lacking support is
deemed negligible.
Validators dropping support for FORMERLY UNIVERSAL algorithms (e.g. 7) without
implementing this specification will produce SERVFAIL responses for
multisigner setups involving the disabled algorithm. Implementation
of the new validation rules is thus advised as soon as support for an
algorithm is dropped.
Since algorithm 8 supports variable key sizes, multisigner
configurations involving 8 and 13 should take care to employ
an RSA keylength that is computationally infeasible to attack.
The minimal proposal in this draft was originally proposed in
by Shumon Huque at the ICANN73 DNSSEC
and Security workshop.
The comprehensive approach was originally proposed by Peter Thomassen
and Viktor Dukhovni after discussions on the problem space with
Edward Lewis, Jakob Schlyter, Johan Stenstam, Shumon Huque, Steve
Crocker, and Duane Wessels.
DNSSEC Automation
RFC Adjustments for MultiSigner
This section discusses the multialgorithm requirements on signers and
validators, as specified by the original DNSSEC specification and in
effect until updated by this document. It is included for purely
informational purposes and context.
In addition to the last paragraph of
Section 2.2 quoted earlier, Section 5.11 of
clarifies:
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone.
While it might seem tempting, relaxing this rule without any further
adjustments may not be safe depending on the algorithm combination
involved. In particular, when using an algorithm that is not
universally supported among the resolver population (such as
algorithm 7) together with a supported one (such as algorithm 13),
resolvers may return SERVFAIL under certain circumstances. Zone
owners and signers thus would have to take great care to not leave a
validating resolver without a valid supported path in such
situations, e.g. when transitioning from algorithm 7 to 13.
More explicitly, when the sole signing algorithm used by a zone is
not supported by a given resolver, the resolver will (correctly)
treat that zone as unsigned. However, when attempting to transfer the
domain to another DNS provider through a multisigner setup with a
supported algorithm, affected resolvers presented with the unsupported
signature only will not be able to distinguish this situation from a
downgradetoinsecure attack where the second signature has been
stripped, and will return SERVFAIL.
Although unstated in that document, the above rule prevents this kind
of downgradetoinsecure attack by requiring RRSIGs for all
advertised algorithms; a validator can thus assume that something is
wrong when supported signatures are missing.
As a side effect, the rule also protects against downgradetoweaker
attacks, where an attacker would strip away signatures from signed DNS
responses and only attach one for an algorithm that the attacker is
able to forge. This
property is not a core guarantee of DNSSEC (see below).
In general, when a validating resolver supporting any of the
algorithms listed in a given zone's DS record or TA set responds to a
query without the CD flag set, it may not treat that zone as
insecure, but must return either validated data (AD=1) or RCODE=2
(SERVFAIL). For this purpose, any valid path suffices; the validator
may not apply a "logical AND" approach to all advertised algorithms.
Accordingly, Section 5.11 of DNSSEC
Clarifications states:
This requirement applies to servers, not validators. Validators
SHOULD accept any single valid path. They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, and they MUST NOT insist
that all algorithms signaled in the DNSKEY RRset work.
At first glance, the assertions that (1) the signer provide
signatures for all advertised algorithms while (2) the resolver shall
be content with just one seems somewhat contradictory. However, the
role of the RRSIG rules is to ensure that the resolver will find a
valid path (using a "logical OR" strategy), regardless of which
particular algorithm(s) it supports, and thus be able to distinguish
reliably between "all is in order" (validated data) and a
downgradetoinsecure attack (SERVFAIL).
The above rules are incompatible with certain use cases:

They are impractical to satisfy if DNS providers deployed in
a multisigner configuration are using different signing
algorithms. By extension, it also means that multisigner
techniques cannot be employed to nondisruptively transfer a
signed zone from one DNS provider to another if the providers use
differing algorithms.

The rules further collide with the conflicting goal of
prepublishing the new trust anchor during a zone's algorithm
rollover, while introducing the new algorithm into the zone only
later in the process.

Furthermore, for online signers attempting to deploy multiple
algorithms, producing signatures for several algorithms also
imposes a significant computational burden, unless a selective
algorithm negotiation mechanism is also developed.
As the above rules present a severe limitation for these use cases,
this document proposes to relax them in a way so that the set of
signatures provided is still "large enough" to ensure reliable DNSSEC
operation, while facilitating the above use cases.