Network Working Group J. Abley
Internet-Draft ICANN
Intended status: Informational J. Schlyter
Expires: December 13, 2013 Kirei
G. Bailey
Microsoft
June 11, 2013
DNSSEC Trust Anchor Publication for the Root Zone
draft-jabley-dnssec-trust-anchor-07
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 December 13, 2013.
Copyright Notice
Copyright (c) 2013 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
Abley, et al. Expires December 13, 2013 [Page 1]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Root Zone Trust Anchor Publication . . . . . . . . . . . . . . 4
2.1. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Certificate Signing Request (PKCS#10) . . . . . . . . . . 4
3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . . 5
3.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Signature Verification . . . . . . . . . . . . . . . . . . 6
4. Implementation Considerations . . . . . . . . . . . . . . . . 7
4.1. HTTP Over TLS Transport . . . . . . . . . . . . . . . . . 7
4.2. XML Validation . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Trust Anchor Validation . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Trust Anchor Publication Document Schema . . . . . . 14
Appendix B. Example Signed Trust Anchor Set . . . . . . . . . . . 15
Appendix C. ASN.1 Module for DNS Resource Record . . . . . . . . 16
Appendix D. Historical Note . . . . . . . . . . . . . . . . . . . 17
Appendix E. About this Document . . . . . . . . . . . . . . . . . 18
E.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18
E.2. Document History . . . . . . . . . . . . . . . . . . . . . 18
E.2.1. draft-jabley-dnssec-trust-anchor-00 . . . . . . . . . 18
E.2.2. draft-jabley-dnssec-trust-anchor-01 . . . . . . . . . 18
E.2.3. draft-jabley-dnssec-trust-anchor-02 . . . . . . . . . 18
E.2.4. draft-jabley-dnssec-trust-anchor-04 . . . . . . . . . 18
E.2.5. draft-jabley-dnssec-trust-anchor-05 . . . . . . . . . 18
E.2.6. draft-jabley-dnssec-trust-anchor-06 . . . . . . . . . 18
E.2.7. draft-jabley-dnssec-trust-anchor-07 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Abley, et al. Expires December 13, 2013 [Page 2]
Internet-Draft Root Zone Trust Anchor Publication June 2013
1. Introduction
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
Security extensions to the DNS (DNSSEC) are described in [RFC4033],
[RFC4034], [RFC4035], [RFC4509], [RFC5155] and [RFC5702].
A discussion of operational practices relating to DNSSEC can be found
in [RFC6781].
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. Signatures are validated by following a chain of
signatures to a key called a "trust anchor". The reason for trusting
such a key 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. A detailed description of
corresponding key management practices can be found in [DPS], which
can be retrieved from the IANA Repository located at
.
This document describes the distribution of the DNSSEC trust anchors
from IANA. This document is concerned only with the distribution of
trust anchors for the root zone, although the data formats and the
publication and retrieval methods described here might can be adapted
for other uses.
Abley, et al. Expires December 13, 2013 [Page 3]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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:
o as the hashes of the corresponding DNSKEY records, consistent with
the defined presentation format of Delegation Signer (DS) resource
records [RFC4034], contained within an XML document, as described
in Section 2.1, and
o as Certificate Signing Requests (CSRs) in PKCS#10 format [RFC2986]
for further processing by other entities such as Certification
Authorities and validation of proof of possession of the
corresponding private keys, as described in Section 2.2.
2.1. XML
Trust anchors are published in an XML document whose schema is
described in Appendix A. The document contains a complete set of
trust anchors for the root zone, including anchors suitable for
immediate use and also historical data. Each trust anchor optionally
includes one or more Certificate elements, with Uniform Resource
Locators (URLs) for retrieving corresponding X.509 certificates.
Examples of trust anchors packaged and signed for publication can be
found in Appendix B.
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 [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], 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]
resource record (see Appendix C for attribute definition).
Abley, et al. Expires December 13, 2013 [Page 4]
Internet-Draft Root Zone Trust Anchor Publication June 2013
3. Root Zone Trust Anchor Retrieval
3.1. HTTP
Trust anchors are available for retrieval using HTTP [RFC2616].
The URL for retrieving the CSR is
, with "key-label"
replaced by the key label of the corresponding KSK.
The URL for retrieving a signed X.509 certificate is
, with "key-label"
again replaced as described above.
The URL for retrieving the complete trust anchor set is
.
The URL for a detached S/MIME [RFC5751] signature for the current
trust anchor set, in XML format, is
.
The URL for a detached OpenPGP [RFC4880] signature for the current
trust anchor set, in XML format, is
.
3.2. HTTP Over TLS
Trust anchors are available for retrieval using HTTP over TLS
[RFC2818].
The URLs specified in Section 3.1 are also available using HTTPS.
That is:
The URL for retrieving the CSR is
, with "key-label"
replaced by the key label of the corresponding KSK.
The URL for retrieving a signed X.509 certificate is
, with "key-label"
again replaced as described above.
The URL for retrieving the complete trust anchor set is
.
The URL for a detached S/MIME [RFC5751] signature for the current
trust anchor set is
.
Abley, et al. Expires December 13, 2013 [Page 5]
Internet-Draft Root Zone Trust Anchor Publication June 2013
The URL for a detached OpenPGP [RFC4880] signature for the current
trust anchor set is
.
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] 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
. 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] signatures for the
current trust anchor set, in XML format, are 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.
Abley, et al. Expires December 13, 2013 [Page 6]
Internet-Draft Root Zone Trust Anchor Publication June 2013
4. Implementation Considerations
Note: This non-normative section gives suggestions for implementing
root zone trust anchor retrieval.
Root trust anchor retrieval by the HTTP or HTTP over TLS transports
has several implementation considerations to ensure robustness,
usability and secure operation.
4.1. HTTP Over TLS Transport
The HTTP over TLS transport [RFC2818] is suggested over the
unencrypted HTTP transport [RFC2616] for implementations using the
XML-format root trust anchors, since the latter transport does not
provide authentication. It is not suggested that implementations
restrict certification path validation of the HTTP over TLS transport
session to the current or historical certificate authorities used by
the root trust anchor server, since doing so would reduce robustness
of the implementation. It is suggested that the implementation
configure the HTTP over TLS transport library to validate the
certification path against certificate revocation lists [RFC5280],
and reject self-signed certificates and certification paths that do
not terminate in a trusted certificate authority.
Implementations can allow configuration of the URL used to retrieve
the root trust anchor resources, but it is suggested that the default
configuration use the URLs specified in Section 3.2.
4.2. XML Validation
Implementations may perform strict validation of the retrieved XML
document against the XML schema; however, such an implementation
would not be robust against future changes in the XML schema. It is
suggested that the implementation perform "loose" validation, where
unknown attributes and elements are ignored. This suggestion allows
for future additions to the XML schema without affecting existing
implementations.
4.3. Trust Anchor Validation
The implementation can ignore trust anchors for which the Algorithm
or DigestType elements refer to an unknown, or unsupported algorithm.
Additionally, trust anchors for which the Algorithm or DigestType
elements refer to a deprecated algorithm can be ignored, provided
that this suggestion does not cause all trust anchors to be ignored.
Further, note that these suggestions may not apply where an
implementation shares trust anchors between many DNS validating
resolvers, since the set of supported algorithms may vary between
Abley, et al. Expires December 13, 2013 [Page 7]
Internet-Draft Root Zone Trust Anchor Publication June 2013
resolvers, and could possibly be disjoint.
The implementation can also ignore a trust anchor when the validUntil
time, if present, is in the past. If the implementation also
supports automated updates of trust anchors [RFC5011], it can ignore
trust anchors where the current time subtracted from the validFrom
time, if present, is greater than the add-hold down time [RFC5011]
for the trust point.
The implementation can reject any trust anchor for a trust point
other than the root zone.
Abley, et al. Expires December 13, 2013 [Page 8]
Internet-Draft Root Zone Trust Anchor Publication June 2013
5. 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 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.
Abley, et al. Expires December 13, 2013 [Page 9]
Internet-Draft Root Zone Trust Anchor Publication June 2013
6. 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.
Abley, et al. Expires December 13, 2013 [Page 10]
Internet-Draft Root Zone Trust Anchor Publication June 2013
7. 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.
Abley, et al. Expires December 13, 2013 [Page 11]
Internet-Draft Root Zone Trust Anchor Publication June 2013
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
Abley, et al. Expires December 13, 2013 [Page 12]
Internet-Draft Root Zone Trust Anchor Publication June 2013
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
December 2012.
8.2. Informative References
[DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter,
"DNSSEC Practice Statement for the Root Zone KSK
Operator", May 2010.
Abley, et al. Expires December 13, 2013 [Page 13]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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 },
element Certificate {
attribute source { xsd:string },
empty
}+
}
Figure 1
Abley, et al. Expires December 13, 2013 [Page 14]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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
.
.
34291
5
1
c8cb3d7fe518835490af8029c23efbce6b6ef3e2
12345
5
1
a3cf809dbdbc835716ba22bdc370d2efa50f21c7
Figure 2
Abley, et al. Expires December 13, 2013 [Page 15]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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
Abley, et al. Expires December 13, 2013 [Page 16]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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.
Abley, et al. Expires December 13, 2013 [Page 17]
Internet-Draft Root Zone Trust Anchor Publication June 2013
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.
E.2.3. draft-jabley-dnssec-trust-anchor-02
Draft expired.
E.2.4. draft-jabley-dnssec-trust-anchor-04
Added the optional element to the XML schema to provide
a mechanism for locating external X.509 certificates relating to a
particular key.
E.2.5. draft-jabley-dnssec-trust-anchor-05
Update author address.
E.2.6. draft-jabley-dnssec-trust-anchor-06
Update references.
Abley, et al. Expires December 13, 2013 [Page 18]
Internet-Draft Root Zone Trust Anchor Publication June 2013
E.2.7. draft-jabley-dnssec-trust-anchor-07
Minor changes based on review by Paul Hoffman.
Abley, et al. Expires December 13, 2013 [Page 19]
Internet-Draft Root Zone Trust Anchor Publication June 2013
Authors' Addresses
Joe Abley
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
US
Phone: +1 519 670 9327
Email: joe.abley@icann.org
Jakob Schlyter
Kirei AB
Email: jakob@kirei.se
Guy Bailey
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Phone: +1 425 538 6153 x86153
Email: gubailey@microsoft.com
Abley, et al. Expires December 13, 2013 [Page 20]