DNSSEC Trust Anchor Publication for the Root Zone
draft-jabley-dnssec-trust-anchor-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 how such trust anchors are published.

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 http://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 April 22, 2011.

Copyright Notice

Copyright (c) 2010 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Root Zone Trust Anchor Publication
    2.1.  XML
    2.2.  Certificate Signing Request (PKCS#10)
3.  Root Zone Trust Anchor Retrieval
    3.1.  HTTP
    3.2.  HTTP Over TLS
    3.3.  Signature Verification
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Trust Anchor Publication Document Schema
Appendix B.  Example Signed Trust Anchor Set
Appendix C.  ASN.1 Module for DNS Resource Record
Appendix D.  Historical Note
Appendix E.  About this Document
    E.1.  Discussion
    E.2.  Document History
        E.2.1.  draft-jabley-dnssec-trust-anchor-00
        E.2.2.  draft-jabley-dnssec-trust-anchor-01
§  Authors' Addresses

1.  Introduction

The Domain Name System (DNS) is described in [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) and [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). Security extensions to the DNS (DNSSEC) are described in [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.), [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.), [RFC4509] (Hardaker, W., “Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs),” May 2006.), [RFC5155] (Laurie, B., Sisson, G., Arends, R., and D. Blacka, “DNS Security (DNSSEC) Hashed Authenticated Denial of Existence,” March 2008.) and [RFC5702] (Jansen, J., “Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC,” October 2009.).

A discussion of operational practices relating to DNSSEC can be found in [RFC4641] (Kolkman, O. and R. Gieben, “DNSSEC Operational Practices,” September 2006.).

In DNSSEC resource record sets (RRSets) are cryptographically-signed, such that a response to a query contains signatures which allow its integrity and authenticity to be verified. An individual signature is validated by following a chain of signatures to a key which is trusted for some extra-protocol reason.

The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN. A detailed description of corresponding key management practices can be found in [DPS] (Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, “DNSSEC Practice Statement for the Root Zone KSK Operator,” May 2010.), which can be retrieved from the IANA Repository located at https://www.iana.org/dnssec/.

This document describes the distribution of DNSSEC trust anchors. Whilst the data formats and the publication and retrieval methods described in this document might well be adapted for other uses, this document's focus is more specific and is concerned only with the distribution of trust anchors for the root zone.

2.  Root Zone Trust Anchor Publication

Trust anchors for the root zone are published in two formats, each of which is described in this document:

• as the hashes of the corresponding DNSKEY records, consistent with the defined presentation format of Delegation Signer (DS) resource records [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.), contained within an XML document, as described in Section 2.1 (XML), and
• as Certificate Signing Requests (CSRs) in PKCS#10 format [RFC2986] (Nystrom, M. and B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7,” November 2000.) for further processing by Certification Authorities and validation of proof of possession of the corresponding private keys, as described in Section 2.2 (Certificate Signing Request (PKCS#10)).

2.1.  XML

Trust anchors are published in an XML document whose schema is described in Appendix A (Trust Anchor Publication Document Schema). The document contains a complete set of trust anchors for the root zone, including anchors suitable for immediate use and also historical data.

Examples of trust anchors packaged and signed for publication can be found in Appendix B (Example Signed Trust Anchor Set).

2.2.  Certificate Signing Request (PKCS#10)

To facilitate signing the trust anchor by a public key infrastructure, trust anchors are also published as Certificate Signing Requests (CSRs) in PKCS#10 format (Nystrom, M. and B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7,” November 2000.) [RFC2986].

Each CSR will have a Subject with following attributes:

O:

the string "ICANN".

OU:

the string "IANA".

CN:

the string "Root Zone KSK" followed by the time and date of key generation in the format specified in [RFC3339] (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.), e.g. "Root Zone KSK 2010-06-16T21:19:24+00:00".

resourceRecord:

the hash of the public key consistent with the presentation format of the Delegation Signer (DS) [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) resource record (see Appendix C (ASN.1 Module for DNS Resource Record) for attribute definition).

3.  Root Zone Trust Anchor Retrieval

3.1.  HTTP

Trust anchors are available for retrieval using HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.).

The URL for retrieving the CSR is <http://data.iana.org/root-anchors/key-label.csr>, with "key-label" replaced by the key label of the corresponding KSK.

The URL for retrieving the IANA-signed Certificate is <http://data.iana.org/root-anchors/key-label.crt>, with "key-label" again replaced as described above.

The URL for retrieving the complete trust anchor set is http://data.iana.org/root-anchors/root-anchors.xml.

The URL for a detached S/MIME [RFC5751] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.) signature for the current trust anchor set is http://data.iana.org/root-anchors/root-anchors.p7s.

The URL for a detached OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) signature for the current trust anchor set is http://data.iana.org/root-anchors/root-anchors.asc.

3.2.  HTTP Over TLS

Trust anchors are available for retrieval using HTTP over TLS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.).

The URLs specified in Section 3.1 (HTTP) are also available using HTTPS. That is:

The URL for retrieving the CSR is <https://data.iana.org/root-anchors/key-label.csr>, with "key-label" replaced by the key label of the corresponding KSK.

The URL for retrieving the IANA-signed Certificate is <https://data.iana.org/root-anchors/key-label.crt>, with "key-label" again replaced as described above.

The URL for retrieving the complete trust anchor set is https://data.iana.org/root-anchors/root-anchors.xml.

The URL for a detached S/MIME [RFC5751] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.) signature for the current trust anchor set is https://data.iana.org/root-anchors/root-anchors.p7s.

The URL for a detached OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) signature for the current trust anchor set is https://data.iana.org/root-anchors/root-anchors.asc.

TLS sessions are authenticated with certificates presented from the server. No client certificate verification is performed. The certificate presented by the server is chosen such that it can be trusted using an X.509 trust anchor that is believed to be well-known, e.g. one that corresponds to a WebTrust-accredited Certificate Authority. Other TLS authentication mechanisms may be considered in the future.

3.3.  Signature Verification

The OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) keys used to sign trust anchor documents carry signatures from personal keys of staff who are able to personally attest to their validity. Those staff members will continue to make their personal keys freely available for examination by third parties, e.g. by way of PGP key parties at operator and IETF meetings. In this fashion a diverse set of paths through the PGP web of trust will be maintained to the trust anchor PGP keys.

An OpenPGP keyring containing public keys pertinent to signature verification is published at http://data.iana.org/root-anchors/icann.pgp. The public keys on that keyring will also be distributed widely, e.g. to public PGP key servers.

Certificates used to create S/MIME [RFC5751] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.) signatures will be signed by a Certificate Authority (CA) administered by ICANN as the IANA functions operator and also optionally by well-known (e.g. WebTrust-certified) CAs to facilitate signature validation with widely-available X.509 trust anchors.

4.  IANA Considerations

Key Signing Key (KSK) management for the root zone is an IANA function. This document describes an initial set of publication mechanisms for trust anchors related to that management. In the future, additional publication schemes may be also be made available, in which case they will be described in a new document that updates this one.

Existing mechanisms will not be deprecated without very strong technical justification.

This document contains information about an existing service, and has no IANA actions.

5.  Security Considerations

This document describes how DNSSEC trust anchors for the root zone of the DNS are published. It is to be expected that many DNSSEC clients will only configure a single trust anchor to perform validation, and that the trust anchor they use will be that of the root zone. 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, as an aid to the formats and retrieval methods described here being integrated usefully into user environments.

6.  Acknowledgements

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.

This document incorporates suggestions made by Paul Hoffman and Alfred Hoenes, whose contributions are appreciated.

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Trust Anchor Publication Document Schema

A Relax NG Compact Schema for the documents used to publish trust anchors can be found 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 }
}

Appendix B.  Example Signed Trust Anchor Set

Figure 2 describes two trust anchors for the root zone such as might be retrieved using the URL https://data.iana.org/root-anchors/root-anchors.xml.

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

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

Appendix C.  ASN.1 Module for DNS Resource Record

ResourceRecord
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

caseIgnoreMatch FROM SelectedAttributeTypes
    { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }

;

iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    dod(6) internet(1) private(4) enterprise(1) 1000 }

iana-dns OBJECT IDENTIFIER ::= { iana 53 }

resourceRecord ATTRIBUTE ::= {
    WITH SYNTAX IA5String
    EQUALITY MATCHING RULE caseIgnoreIA5Match
    ID iana-dns
}

END

Appendix D.  Historical Note

The first KSK for use in the root zone of the DNS was generated at a key ceremony at an 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.

Appendix E.  About this Document

[RFC Editor: please remove this section, including all subsections, prior to publication.]

E.1.  Discussion

This document is not the product of any IETF working group. However, communities interested in similar technical work can be found at the IETF in the DNSOP and DNSEXT working groups.

The team responsible for deployment of DNSSEC in the root zone can be reached at rootsign@icann.org.

The authors also welcome feedback sent to them directly.

E.2.  Document History

E.2.1.  draft-jabley-dnssec-trust-anchor-00

This document is based on earlier documentation used within and published by the team responsible for DNSSEC deployment in the root zone. This is the first revision circulated with the intention of publication in the RFC series.

E.2.2.  draft-jabley-dnssec-trust-anchor-01

Incorporated initial community suggestions. Editorial improvements. Allocate OID and clean up syntax of ASN.1 module.

Authors' Addresses