Internet DRAFT - draft-ietf-dnsop-rfc7958bis

draft-ietf-dnsop-rfc7958bis







Network Working Group                                           J. Abley
Internet-Draft                                                Cloudflare
Obsoletes: 7958 (if approved)                                J. Schlyter
Intended status: Informational                                  Kirei AB
Expires: 5 September 2024                                      G. Bailey
                                                             Independent
                                                              P. Hoffman
                                                                   ICANN
                                                            4 March 2024


           DNSSEC Trust Anchor Publication for the Root Zone
                     draft-ietf-dnsop-rfc7958bis-01

Abstract

   The root zone of the Domain Name System (DNS) has been
   cryptographically signed using DNS Security Extensions (DNSSEC).

   In order to obtain secure answers from the root zone of the DNS using
   DNSSEC, a client must configure a suitable trust anchor.  This
   document describes the format and publication mechanisms IANA uses to
   distribute the DNSSEC trust anchors.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/.

   Source for this draft and an issue tracker can be found at
   https://github.com/paulehoffman/draft-bash-rfc7958bis.

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



Abley, et al.           Expires 5 September 2024                [Page 1]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Changes from RFC 7958 . . . . . . . . . . . . . . . . . .   4
   2.  IANA DNSSEC Root Zone Trust Anchor Format and Semantics . . .   4
     2.1.  XML Syntax  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  XML Semantics . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Converting from XML to DS Records . . . . . . . . . . . .   7
     2.4.  Converting from XML to DNSKEY Records . . . . . . . . . .   7
     2.5.  XML Example . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Root Zone Trust Anchor Retrieval  . . . . . . . . . . . . . .   8
     3.1.  Retrieving Trust Anchors with HTTPS and HTTP  . . . . . .   8
     3.2.  Accepting DNSSEC Trust Anchors  . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Historical Note  . . . . . . . . . . . . . . . . . .  11
   Appendix B.  Acknowledgemwents  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
   DNS Security Extensions (DNSSEC) are described in [RFC9364].









Abley, et al.           Expires 5 September 2024                [Page 2]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   In the DNSSEC protocol, Resource Record Sets (RRSets) are signed
   cryptographically.  This means that a response to a query contains
   signatures that allow the integrity and authenticity of the RRSet to
   be verified.  DNSSEC signatures are validated by following a chain of
   signatures to a "trust anchor".  The reason for trusting a trust
   anchor is outside the DNSSEC protocol, but having one or more trust
   anchors is required for the DNSSEC protocol to work.

   The publication of trust anchors for the root zone of the DNS is an
   IANA function performed by ICANN, through its affiliate Public
   Technical Identifiers (PTI).  A detailed description of corresponding
   key management practices can be found in [DPS].

   This document describes the formats and distribution methods of
   DNSSEC trust anchors that have been used by IANA for the root zone of
   the DNS since 2010.  Other organizations might have different formats
   and mechanisms for distributing DNSSEC trust anchors for the root
   zone; however, most operators and software vendors have chosen to
   rely on the IANA trust anchors.

   The formats and distribution methods described in this document are a
   complement to, not a substitute for, the automated DNSSEC trust
   anchor update protocol described in [RFC5011].  That protocol allows
   for secure in-band succession of trust anchors when trust has already
   been established.  This document describes one way to establish an
   initial trust anchor that can be used by RFC 5011.

1.1.  Definitions

   The term "trust anchor" is used in many different contexts in the
   security community.  Many of the common definitions conflict because
   they are specific to a specific system, such as just for DNSSEC or
   just for S/MIME messages.

   In cryptographic systems with hierarchical structure, a trust anchor
   is an authoritative entity for which trust is assumed and not
   derived.  The format of the entity differs in different systems, but
   the basic idea, that trust is assumed and not derived, is common to
   all the common uses of the term "trust anchor".

   The root zone trust anchor formats published by IANA are defined in
   Section 2.  [RFC4033] defines a trust anchor as "A configured DNSKEY
   RR or DS RR hash of a DNSKEY RR".  Note that the formats defined here
   do not match the definition of "trust anchor" from [RFC4033];
   however, a system that wants to convert the trusted material from
   IANA into a Delegation Signer (DS) RR can do so.





Abley, et al.           Expires 5 September 2024                [Page 3]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Changes from RFC 7958

   This version of the document includes the following changes:

   *  There is a signficant technical change from erratum 5932
      <https://www.rfc-editor.org/errata/eid5932>.  This is in the
      seventh paragraph of Section 2.2.

   *  Added the optional public key element.

   *  Removed the certificates and certificate signing mechanisms.

   *  Removed the detached OpenPGP signature mechanism.

   *  The reference to the DNSSEC Practice Statement [DPS] was updated.

   *  Say explicitly that the XML documents might have XML comments in
      them.

2.  IANA DNSSEC Root Zone Trust Anchor Format and Semantics

   IANA publishes trust anchors for the root zone as an XML document
   that contains the hashes of the DNSKEY records and optionally the
   keys from the DNSKEY records.

   This format and the semantics associated are described in the rest of
   this section.

   Note that the XML document can have XML comments.  For example, IANA
   might use these comments to add pointers to important information on
   the IANA web site.  XML comments are only used as human-readable
   commentary, not extensions to the grammar.

   The XML document contains a set of hashes for the DNSKEY records that
   can be used to validate the root zone.  The hashes are consistent
   with the defined presentation format of DS resource.

   The XML document also can contain the keys from the DNSKEY records.
   The keys are consistent with the defined presentation format of
   DNSKEY resource.





Abley, et al.           Expires 5 September 2024                [Page 4]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   Note that the hashes are mandatory in the syntax, but the keys are
   optional.

2.1.  XML Syntax

   A RELAX NG Compact Schema [RELAX-NG] for the documents used to
   publish trust anchors is given in Figure 1.

   datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"

   start = element TrustAnchor {
       attribute id { xsd:string },
       attribute source { xsd:string },
       element Zone { xsd:string },

       keydigest+
   }

   keydigest = element KeyDigest {
       attribute id { xsd:string },
       attribute validFrom { xsd:dateTime },
       attribute validUntil { xsd:dateTime }?,

       element KeyTag {
               xsd:nonNegativeInteger { maxInclusive = "65535" } },
       element Algorithm {
               xsd:nonNegativeInteger { maxInclusive = "255" } },
       element DigestType {
               xsd:nonNegativeInteger { maxInclusive = "255" } },
       element Digest { xsd:hexBinary },
       element PublicKey { xsd:base64Binary }?
   }
                              Figure 1

2.2.  XML Semantics

   The TrustAnchor element is the container for all of the trust anchors
   in the file.

   The id attribute in the TrustAnchor element is an opaque string that
   identifies the set of trust anchors.  Its value has no particular
   semantics.  Note that the id element in the TrustAnchor element is
   different than the id element in the KeyDigest element, described
   below.

   The source attribute in the TrustAnchor element gives information
   about where to obtain the TrustAnchor container.  It is likely to be
   a URL and is advisory only.



Abley, et al.           Expires 5 September 2024                [Page 5]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   The Zone element in the TrustAnchor element states to which DNS zone
   this container applies.  The root zone is indicated by a single
   period (.) character without any quotation marks.

   The TrustAnchor element contains one or more KeyDigest elements.
   Each KeyDigest element represents the digest of a DNSKEY record in
   the zone defined in the Zone element.

   The id attribute in the KeyDigest element is an opaque string that
   identifies the hash.  Note that the id element in the KeyDigest
   element is different than the id element in the TrustAnchor element
   described above.

   The validFrom and validUntil attributes in the KeyDigest element
   specify the range of times that the KeyDigest element can be used as
   a trust anchor.  Note that the validUntil attribute of the KeyDigest
   element is optional.  If the relying party is using a trust anchor
   that has a KeyDigest element that does not have a validUntil
   attribute, it can change to a trust anchor with a KeyDigest element
   that does have a validUntil attribute, as long as that trust anchor's
   validUntil attribute is in the future and the DNSKEY elements of the
   KeyDigest are the same as the previous trust anchor.  Relying parties
   SHOULD NOT use a KeyDigest outside of the time range given in the
   validFrom and validUntil attributes.

   The KeyTag element in the KeyDigest element contains the key tag for
   the DNSKEY record represented in this KeyDigest.

   The Algorithm element in the KeyDigest element contains the signing
   algorithm identifier for the DNSKEY record represented in this
   KeyDigest.

   The DigestType element in the KeyDigest element contains the digest
   algorithm identifier for the DNSKEY record represented in this
   KeyDigest.

   The Digest element in the KeyDigest element contains the hexadecimal
   representation of the hash for the DNSKEY record represented in this
   KeyDigest.

   The PublicKey element in the KeyDigest element contains the base64
   representation of the public key represented in this KeyDigest.  The
   PublicKey is optional and is new in this version of the
   specification.







Abley, et al.           Expires 5 September 2024                [Page 6]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


2.3.  Converting from XML to DS Records

   The display format for the DS record that is the equivalent of a
   KeyDigest element can be constructed by marshaling the KeyTag,
   Algorithm, DigestType, and Digest elements.  For example, assume that
   the TrustAnchor element contains:

   <?xml version="1.0" encoding="UTF-8"?>
   <TrustAnchor
      id="AD42165F-3B1A-4778-8F42-D34A1D41FD93"
      source="http://data.iana.org/root-anchors/root-anchors.xml">
   <Zone>.</Zone>
   <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00">
   <KeyTag>19036</KeyTag>
   <Algorithm>8</Algorithm>
   <DigestType>2</DigestType>
   <Digest>
   49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
   </Digest>
   <PublicKey>
   AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
   FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
   bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
   X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
   W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
   Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
   QxA+Uk1ihz0=
   </PublicKey>
   </KeyDigest>
   </TrustAnchor>

   The DS record would be:

   . IN DS 19036 8 2
      49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

2.4.  Converting from XML to DNSKEY Records

   The display format for the DNSKEY record that is the equivalent of a
   KeyDigest element can be constructed by marshaling the Algorithm and
   PublicKey elements with some constants.  For example, assume that the
   TrustAnchor element is the same as in Section 2.3.  The DNSKEY record
   would be:








Abley, et al.           Expires 5 September 2024                [Page 7]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   . IN DNSKEY 257 3 8
      AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
      FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
      bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
      X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
      W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
      Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
      QxA+Uk1ihz0=

2.5.  XML Example

   Figure 2 describes two fictitious trust anchors for the root zone.

   <?xml version="1.0" encoding="UTF-8"?>

   <!-- Note that these trust anchors are fictitious. -->

   <TrustAnchor
       id="AD42165F-B099-4778-8F42-D34A1D41FD93"
       source="http://data.iana.org/root-anchors/root-anchors.xml">
       <Zone>.</Zone>
       <KeyDigest id="42"
                  validFrom="2010-07-01T00:00:00-00:00"
                  validUntil="2010-08-01T00:00:00-00:00"> <!-- This key
       is no longer valid, since validUntil is in the past -->
           <KeyTag>34291</KeyTag>
           <Algorithm>5</Algorithm>
           <DigestType>1</DigestType>
           <Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
       </KeyDigest>
       <KeyDigest id="53"
                  validFrom="2010-08-01T00:00:00-00:00">
           <KeyTag>12345</KeyTag>
           <Algorithm>5</Algorithm>
           <DigestType>1</DigestType>
           <Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
       </KeyDigest>
   </TrustAnchor>

                              Figure 2

3.  Root Zone Trust Anchor Retrieval

3.1.  Retrieving Trust Anchors with HTTPS and HTTP

   Trust anchors are available for retrieval using HTTPS and HTTP.





Abley, et al.           Expires 5 September 2024                [Page 8]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   In this section, all URLs are given using the "https:" scheme.  If
   HTTPS cannot be used, replace the "https:" scheme with "http:".

   The URL for retrieving the set of hashes in the XML file described in
   Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>.

3.2.  Accepting DNSSEC Trust Anchors

   A validator operator can choose whether or not to accept the trust
   anchors described in this document using whatever policy they want.
   In order to help validator operators verify the content and origin of
   trust anchors they receive, IANA uses digital signatures that chain
   to an ICANN-controlled Certificate Authority (CA) over the trust
   anchor data.

   It is important to note that the ICANN CA is not a DNSSEC trust
   anchor.  Instead, it is an optional mechanism for verifying the
   content and origin of the XML and certificate trust anchors.

   The content and origin of the XML file can be verified using a
   digital signature on the file.  IANA provides a detached
   Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to
   the ICANN CA with the XML file.  The URL for a detached CMS signature
   for the XML file is <https://data.iana.org/root-anchors/root-
   anchors.p7s>.

   Another method IANA uses to help validator operators verify the
   content and origin of trust anchors they receive is to use the
   Transport Layer Security (TLS) protocol for distributing the trust
   anchors.  Currently, the CA used for data.iana.org is well known,
   that is, one that is a WebTrust-accredited CA.  If a system
   retrieving the trust anchors trusts the CA that IANA uses for the
   "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in
   order to have assurance of data origin.

4.  Security Considerations

   This document describes how DNSSEC trust anchors for the root zone of
   the DNS are published.  Many DNSSEC clients will only configure IANA-
   issued trust anchors for the DNS root to perform validation.  As a
   consequence, reliable publication of trust anchors is important.

   This document aims to specify carefully the means by which such trust
   anchors are published, with the goal of making it easier for those
   trust anchors to be integrated into user environments.

5.  References




Abley, et al.           Expires 5 September 2024                [Page 9]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


5.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/rfc/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [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/rfc/rfc4033>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

5.2.  Informative References

   [DPS]      Root Zone KSK Operator Policy Management Authority,
              "DNSSEC Practice Statement for the Root Zone KSK
              Operator", 2020, <https://www.iana.org/dnssec/procedures>.

   [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", 2002,
              <https://www.oasis-open.org/committees/relax-ng/compact-
              20021121.html>.






Abley, et al.           Expires 5 September 2024               [Page 10]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


Appendix A.  Historical Note

   The first KSK for use in the root zone of the DNS was generated at a
   key ceremony at the ICANN Key Management Facility (KMF) in Culpeper,
   Virginia, USA on 2010-06-16.  This key entered production during a
   second key ceremony held at an ICANN KMF in El Segundo, California,
   USA on 2010-07-12.  The resulting trust anchor was first published on
   2010-07-15.

   The second KSK for use in the root zone of the DNS was generated at
   key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on
   2016-10-27.  This key entered production during key ceremony #28 held
   at the ICANN KMF in El Segundo, California, USA on 2017-02-02.  The
   resulting trust anchor was first published on 2018-11-11.

   More information about the key ceremonies, including full records of
   previous ceremonies and plans for future ceremonies, can be found at
   <https://www.iana.org/dnssec/ceremonies>.

Appendix B.  Acknowledgemwents

   Many pioneers paved the way for the deployment of DNSSEC in the root
   zone of the DNS, and the authors hereby acknowledge their substantial
   collective contribution.

   RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ
   Housley, whose contributions are appreciated.

Authors' Addresses

   Joe Abley
   Cloudflare
   Amsterdam
   Netherlands
   Email: jabley@cloudflare.com


   Jakob Schlyter
   Kirei AB
   Email: jakob@kirei.se


   Guillaume Bailey
   Independent
   Email: guillaumebailey@outlook.com






Abley, et al.           Expires 5 September 2024               [Page 11]

Internet-Draft     Root Zone Trust Anchor Publication         March 2024


   Paul Hoffman
   ICANN
   Email: paul.hoffman@icann.org
















































Abley, et al.           Expires 5 September 2024               [Page 12]