Internet DRAFT - draft-huque-dnsop-multi-alg-rules
draft-huque-dnsop-multi-alg-rules
Internet Engineering Task Force S. Huque
Internet-Draft Salesforce
Updates: 4035, 6840, 8624 (if approved) P. Thomassen
Intended status: Standards Track deSEC, SSE
Expires: 10 May 2024 V. Dukhovni
Google LLC
D. Wessels
Verisign
7 November 2023
Multiple Algorithm Rules in DNSSEC
draft-huque-dnsop-multi-alg-rules-02
Abstract
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 multi-
signer operation and for the transfer of signed DNS zones between
providers, where the providers support disjoint DNSSEC algorithm
sets. In addition, the proposal enables pre-publication 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
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/shuque/draft-dnsop-multi-alg-rules.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Huque, et al. Expires 10 May 2024 [Page 1]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Proposed Updates to RFCs . . . . . . . . . . . . . . . . . . 4
2.1. Minimal Approach . . . . . . . . . . . . . . . . . . . . 4
2.2. Comprehensive Approach . . . . . . . . . . . . . . . . . 5
2.2.1. Updates to RFC 8624 . . . . . . . . . . . . . . . . . 5
2.2.2. Signer Requirements . . . . . . . . . . . . . . . . . 6
2.2.3. Validator Requirements . . . . . . . . . . . . . . . 6
2.2.4. Discussion . . . . . . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Minimal approach . . . . . . . . . . . . . . . . . . . . 8
4.2. Comprehensive approach . . . . . . . . . . . . . . . . . 8
4.2.1. Time Dependency of UNIVERSAL Algorithms . . . . . . . 9
4.3. Variable Key Size Algorithms . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . 11
Appendix A. Current Multiple Algorithm Rules . . . . . . . . . . 11
A.1. Signing Requirements . . . . . . . . . . . . . . . . . . 11
A.2. Validator Requirements . . . . . . . . . . . . . . . . . 12
A.3. Incompatible Use Cases . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Huque, et al. Expires 10 May 2024 [Page 2]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
1. Introduction and Motivation
The Domain Name System Security Extensions (DNSSEC) [RFC4033]
[RFC4034] [RFC4035] 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 [RFC4035][RFC6840] 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 multi-signer setups (Multi-Signer Extensions [RFC8901]
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 [DNSSEC-AUTO] further describes how to fully
automate Multi-Signer operations, including how to use a
transitional state of a multi-signer configuration to non-
disruptively 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
double-signed 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 double-signing (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
Huque, et al. Expires 10 May 2024 [Page 3]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
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.
2. Proposed Updates to RFCs
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 [RFC4035]:
| 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.
2.1. Minimal Approach
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.
Huque, et al. Expires 10 May 2024 [Page 4]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
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 multi-signer 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.
2.2. Comprehensive Approach
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 multi-signer
operation and TA pre-publication are made possible, without risking
validation failures.
For the case of a multi-signer setup with two generally supported
algorithms (such as 8 and 13), the scheme requires only one of the
two signatures. Similarly, when pre-publishing a trust anchor,
associated signatures don't need to be published immediately,
provided that the existing TA's algorithm is generally supported.
2.2.1. Updates to RFC 8624
The notion of UNIVERSAL signing algorithms is introduced, and defined
as follows:
* The information contained in the table of [RFC8624] Section 3.1 is
transferred into a to-be-erected 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.
Huque, et al. Expires 10 May 2024 [Page 5]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
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? ]
2.2.2. Signer Requirements
1. 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.
2. 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.
2.2.3. Validator Requirements
1. 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.
2. 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 multi-signer, multi-algorithm setup.
Huque, et al. Expires 10 May 2024 [Page 6]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
2.2.4. Discussion
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 multi-signer 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
(Section 4.2).
DNS operators in a multi-signer 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 dual-signing 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.
3. IANA Considerations
The minimal approach (Section 2.1) has no IANA actions.
Huque, et al. Expires 10 May 2024 [Page 7]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
When the comprehensive approach (Section 2.2) 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.
4. Security Considerations
4.1. Minimal approach
The minimal approach requires the zone owner and signer(s) to take
great care in order to not break working setups by entering a multi-
signer 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 multi-
signer 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.
4.2. Comprehensive approach
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 multi-provider 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
multi-provider 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 multi-provider 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, non-supporting validators may treat the zone as insecure.
This resolves undue SERVFAIL issues that could occur with certain
algorithm combinations under the previous rules.
Huque, et al. Expires 10 May 2024 [Page 8]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
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 multi-signer
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 glitch-
free 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 multi-signer setup, the zone
maintainer needs to move from the FORMERLY UNIVERSAL algorithm to a
UNIVERSAL one in order to restore universal validation.
4.2.1. Time Dependency of UNIVERSAL Algorithms
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 non-supporting 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
non-negligible 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 multi-signer setups involving the disabled algorithm.
Implementation of the new validation rules is thus advised as soon as
support for an algorithm is dropped.
Huque, et al. Expires 10 May 2024 [Page 9]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
4.3. Variable Key Size Algorithms
Since algorithm 8 supports variable key sizes, multi-signer
configurations involving 8 and 13 should take care to employ an RSA
keylength that is computationally infeasible to attack.
5. Acknowledgements
The minimal proposal in this draft was originally proposed in
[ICANN-TALK] 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.
6. Normative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013,
<https://www.rfc-editor.org/info/rfc6840>.
[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
Requirements and Usage Guidance for DNSSEC", RFC 8624,
DOI 10.17487/RFC8624, June 2019,
<https://www.rfc-editor.org/info/rfc8624>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>.
Huque, et al. Expires 10 May 2024 [Page 10]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
7. Informative References
[DNSSEC-AUTO]
Wisser, U. and S. Huque, "DNSSEC Automation",
<https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-
automation-01.html>.
[ICANN-TALK]
Huque, S., "RFC Adjustments for Multi-Signer",
<https://tinyurl.com/multisigner-rfc-adjustments>.
Appendix A. Current Multiple Algorithm Rules
This section discusses the multi-algorithm 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.
A.1. Signing Requirements
In addition to the last paragraph of [RFC4035] Section 2.2 quoted
earlier, Section 5.11 of [RFC6840] 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 multi-signer setup with
a supported algorithm, affected resolvers presented with the
unsupported signature only will not be able to distinguish this
situation from a downgrade-to-insecure attack where the second
signature has been stripped, and will return SERVFAIL.
Although unstated in that document, the above rule prevents this kind
of downgrade-to-insecure attack by requiring RRSIGs for all
advertised algorithms; a validator can thus assume that something is
Huque, et al. Expires 10 May 2024 [Page 11]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
wrong when supported signatures are missing. As a side effect, the
rule also protects against downgrade-to-weaker 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).
A.2. Validator Requirements
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 [RFC6840] 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 downgrade-
to-insecure attack (SERVFAIL).
A.3. Incompatible Use Cases
The above rules are incompatible with certain use cases:
* They are impractical to satisfy 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.
* The rules further collide with the conflicting goal of pre-
publishing the new trust anchor during a zone's algorithm
rollover, while introducing the new algorithm into the zone only
later in the process.
Huque, et al. Expires 10 May 2024 [Page 12]
Internet-Draft Multiple Algorithm Rules in DNSSEC November 2023
* 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.
Authors' Addresses
Shumon Huque
Salesforce
Email: shuque@gmail.com
Peter Thomassen
deSEC, SSE
Email: peter@desec.io
Viktor Dukhovni
Google LLC
Email: ietf-dane@dukhovni.org
Duane Wessels
Verisign
Email: dwessels@verisign.com
Huque, et al. Expires 10 May 2024 [Page 13]