Internet Engineering Task Force S. Huque Internet-Draft Salesforce Updates: 4035, 6840 (if approved) 3 July 2023 Intended status: Standards Track Expires: 4 January 2024 Multiple Algorithm Rules in DNSSEC draft-huque-dnsop-multi-alg-rules-00 Abstract This document proposes to address some limitations in the DNS protocol that pose challenges for configurations of multi-signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. 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/. 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 4 January 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. Huque Expires 4 January 2024 [Page 1] Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023 Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 2. Current Multiple Algorithm Rules . . . . . . . . . . . . . . 2 3. Support for a wide range of validators . . . . . . . . . . . 3 4. Does DNSSEC need algorithm downgrade protection? . . . . . . 4 5. Proposed Updates to RFCs . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction and Motivation 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) [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. The Multi-Signer Extensions [RFC8901] describe how multiple providers using distinct DNSSEC keys can co-operatively serve the same DNS zone. DNSSEC Automation [DNSSEC-AUTO] 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. 2. Current Multiple Algorithm Rules Section 2.2 (last paragraph) of [RFC4035] 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)." Huque Expires 4 January 2024 [Page 2] Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023 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 [RFC6840] 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. 3. Support for a wide range of validators 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. Huque Expires 4 January 2024 [Page 3] Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023 4. Does DNSSEC need algorithm downgrade protection? 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. 5. Proposed Updates to RFCs 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. Huque Expires 4 January 2024 [Page 4] Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023 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. 6. IANA Considerations 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. 7. Security Considerations TBD. 8. Acknowledgements The proposal in this draft was originally presented in [ICANN-TALK] by S. Huque at the ICANN73 DNSSEC and Security workshop. 9. 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, . [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, . [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, . Huque Expires 4 January 2024 [Page 5] Internet-Draft Multiple Algorithm Rules in DNSSEC July 2023 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, . 10. Informative References [DNSSEC-AUTO] Wisser, U. and S. Huque, "DNSSEC Automation", . [ICANN-TALK] Huque, S., "RFC Adjustments for Multi-Signer", . Author's Address Shumon Huque Salesforce 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America Email: shuque@gmail.com Huque Expires 4 January 2024 [Page 6]