Multiple Algorithm Rules in DNSSEC

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: https://github.com/shuque/draft-dnsop-multi-alg-rules 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. The Multi-Signer Extensions describe how multiple providers using distinct DNSSEC keys can co-operatively serve the same DNS zone. DNSSEC Automation further describes how to fully automate Multi-Signer operations, as well as how to use a transitional state of a multi-signer configuration to non-disruptively transfer a signed zone from one provider to another. These methods do not work however if the providers involved employ different DNSSEC algorithms, due to restrictions imposed by the current protocol specifications. This is not just a theoretical problem. Real situations in the field have occurred where this has posed an obstacle to DNSSEC deployment and operations.

Section 2.2 (last paragraph) of states the following: "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)." Although unstated in that document, the original rationale for this rule was algorithm downgrade protection. An attacker cannot undetectably strip away signatures by a stronger algorithm from signed DNS responses. This rule cannot be satisfied if DNS providers deployed in a multi-signer configuration are using different signing algorithms. By extension, it also means that multi-signer techniques cannot be employed to non-disruptively transfer a signed zone from one DNS provider to another if the providers use differing algorithms. For online signers attempting to deploy multiple algorithms, this rule also imposes a significant computational burden, unless a selective algorithm negotiation mechanism is also developed. On the other hand, Section 5.11 of DNSSEC Clarifications referring to the above rule states that: "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." Effectively, this means that any validator following this rule does not provide algorithm downgrade protection, rendering the requirement in RFC 4035 somewhat meaningless. The two quoted assertions in RFC 4035 and 6840 are thus arguably contradictory.

A secondary reason for the rule in RFC 4035 is that it allows signed data in the zone to be authenticatable by a wide range of validating resolvers that may support different algorithms. This is sound advice as a general rule, and allows a zone operator to introduce a newish algorithm that does not yet have wide support in the field by double signing it with a well known algorithm. But the rule is too rigid to support other reasonable configurations where differing algorithms may be in use, but all of which are very widely supported. Multi-signer and inter-provider transfers involving differing but only well known algorithms are cases in point.

All things being equal, algorithm downgrade protection would be a desirable property. But in general, only the zone owner knows the intent of their use of multiple algorithms. For example, if a zone owner wants to deploy a multi-signer configuration across two providers supporting the algorithms ECDSAP256SHA256 and RSASHA256-3072-bit respectively, it should be possible to do so without unnecessary protocol impediments. Those algorithms are roughly comparable in strength and there is no threat of downgrade attack. More generally, a zone owner can avoid the threat of algorithm downgrade by simply choosing to use only a set of sufficiently strong algorithms. Validators should not unilaterally impose requirements that interfere with the zone owner's actual intentions. In fact, the clarifying behavior of validators in RFC6840 which states that they should accept "any" valid authentication path is compatible with this stance. The emerging threat of quantum computers may offer a more compelling rationale for algorithm downgrade protection. A zone owner could double sign their zone with a classical as well as a post-quantum algorithm, and want to make sure a future break of the classical algorithm does not allow attackers to strip away the post quantum signatures. A secure signaling mechanism that permits a zone owner to advertise their intention in this regard would be useful. Note that presently no post quantum signature algorithms for DNSSEC have been standardized.

Initial proposal: relax the quoted rule in RFC 4035. Change the MUST to a SHOULD, and state that there are valid configurations where this rule could be disregarded. Longer term: develop a scheme to allow a zone owner to securely signal their desire for algorithm downgrade protection. One possible method to do this is a "DS hack": namely overloading the signed DS record set in the parent zone to convey this signal, a technique that has been met with some resistance by protocol purists in the past. Another method would be to define a new resource record type for this purpose. Special consideration would have to given to where such a signal would be placed for the root zone if needed (or whether the root zone should just have a hardcoded rule). Details of such a proposal are deferred to a future document (or a revision of this one). If and when such a proposal is developed, the text in RFC 6840, Section 5.11 will need to be updated to enforce algorithm downgrade protection in the presence of the signal.

Initially none. If a later scheme for algorithm downgrade signaling is developed, new protocol parameter numbers will be needed for DS or a new resource record type.

TBD.

The proposal in this draft was originally presented in by S. Huque at the ICANN73 DNSSEC and Security workshop.