Skip to main content

Multiple Algorithm Rules in DNSSEC
draft-huque-dnsop-multi-alg-rules-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Shumon Huque
Last updated 2023-07-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-huque-dnsop-multi-alg-rules-00
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,
              <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>.

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,
              <https://www.rfc-editor.org/info/rfc6840>.

   [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>.

10.  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>.

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]