One document matched: draft-jabley-dnsop-validator-bootstrap-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
<!ENTITY rfc4035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
<!ENTITY rfc5011 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml'>
<!ENTITY rfc5905 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml'>
<!ENTITY I-D.jabley-dnssec-trust-anchor PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-jabley-dnssec-trust-anchor-01.xml'>
]>
<rfc category="bcp" ipr="trust200902"
docName="draft-jabley-dnsop-validator-bootstrap-00">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Validator Boostrap">Establishing an Appropriate Root
Zone DNSSEC Trust Anchor at Startup</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>ICANN</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</email>
</address>
</author>
<author fullname="Dave Knight" initials="D." surname="Knight">
<organization>ICANN</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<phone>+1 310 913 4512</phone>
<email>dave.knight@icann.org</email>
</address>
</author>
<date day="31" month="January" year="2011"/>
<abstract>
<t>Domain Name System Security Extensions (DNSSEC) allow
cryptographic signatures to be used to validate responses
received from the Domain Name System (DNS). A DNS client
which validates such signatures is known as a validator.</t>
<t>The choice of appropriate root zone trust anchor for a
validator is expected to vary over time as the corresponding
cryptographic keys used in DNSSEC are changed.</t>
<t>This document provides guidance on how validators
might determine an appropriate trust anchor for the root
zone to use at start-up, or when other mechanisms intended
to allow key rollover to be tolerated gracefully are not
available.</t>
</abstract>
</front>
<middle>
<section title="Definitions">
<t>The terms Key Signing Key (KSK) and Trust Anchor are used
as defined in <xref target="RFC4033"/>.</t>
<t>The term Validator is used in this document to mean a
Validating Security-Aware Stub Resolver, as defined in
<xref target="RFC4033"/>.</t>
</section>
<section title="Introduction" anchor="introduction">
<t>The Domain Name System (DNS) is described
in <xref target="RFC1034"/> and <xref target="RFC1035"/>.
DNS Security Extensions (DNSSEC) are described in
<xref target="RFC4033"/>, <xref target="RFC4034"/> and
<xref target="RFC4035"/>.</t>
<t>The root zone of the DNS was signed using DNSSEC in July
2011, and many top-level domain registries have since
signed their zones, installing secure delegations for
them in the root zone. A single trust anchor for the root
zone is hence increasingly sufficient for validators.</t>
<t>Validators are deployed in a variety of environments, and
there is variation in the amount of system administration
that might reasonably be expected to be available. For
example, embedded devices might never be administered by a
human operator, whereas validators deployed on general-purpose
operating systems in enterprise networks might have
technical staff available to assist with their configuration.</t>
<t>This document includes descriptions of mechanisms
for validator bootstrapping, intended to be sufficient for
embedded devices. The implementation of those mechanisms
might be automatic in the case of unattended devices, or
manual, carried out by a systems administrator, depending
on local circumstances.</t>
<t>The choice of appropriate trust anchor for a DNSSEC Validator
is expected to vary over time as the corresponding KSK used
in the root zone is changed. The DNSSEC Policy and Practice
Statement (DPS) for the root zone KSK maintainer <xref
target="KSK-DPS"/> specifies that scheduled KSK rollover
will be undertaken according to the semantics specified in
<xref target="RFC5011"/>. Validators which are able to
recognise and accommodate those semantics should need no
additional support to be able to maintain an appropriate
trust anchor over a root zone KSK rollover event.</t>
<t>The possibility remains, however, that <xref target="RFC5011"/>
signalling will not be available
to a validator: e.g. certain classes of emergency KSK
rollover may require a compromised KSK to be discarded more
quickly than <xref target="RFC5011"/> specifies, or a
validator might be off-line over the whole key-roll event.</t>
<t>This document provides guidance on how DNSSEC Validators
might determine an appropriate set of trust anchors to use
at start-up, or when other mechanisms intended to allow key
rollover to be tolerated gracefully are not available.</t>
<t>The bootstrapping procedures described in this document
are also expected to be useful for a deployed, running
validator which is not able to accommodate a KSK roll using
<xref target="RFC5011"/> signalling.</t>
</section>
<section title="Summary of Approach">
<t>A validator that has no valid trust anchor initialises itself
as follows.</t>
<section title="Initial State">
<t>A validator in its initial state is capable of sending and
receiving DNS queries and responses, but is not capable of
validating signatures received in responses.</t>
<t>A validator must confirm that its local clock is
sufficiently accurate before trust anchors can be
established, and before processing of DNSSEC signatures
can proceed. Discussion of timing considerations can be found
in <xref target="timing"/>.</t>
</section>
<section title="Trust Anchor Retrieval">
<t>Once the local clock has been synchronised, a validator
may proceed to gather candidate trust anchors for consideration.
Discussion of trust anchor retrieval can be found in
<xref target="retrieval"/>.</t>
</section>
<section title="Trust Anchor Selection">
<t>Once a set of candidate trust anchors has been obtained,
a validator attempts to find one trust anchor in the set
which is appropriate for use. This process involves
verification of cryptographic signatures, and is discussed
in <xref target="selection"/>.</t>
</section>
<section title="Full Operation">
<t>The validator now has an accurate trust anchor for the
root zone, and is capable of validating signatures on
responses from the DNS.</t>
</section>
</section>
<section title="Timing Considerations" anchor="timing">
<t>DNSSEC signatures are valid for particular periods of time,
as specified by the administrator of the zone containing
the signatures. It follows that any validator must maintain
an accurate local clock in order to verify that signatures are
accurate.</t>
<t>Trust anchors correspond to KSKs in particular zones. Zone
administrators may choose to replace KSKs from time to time,
e.g. due to a key compromise or local key management policy, and
the corresponding appropriate choice in trust anchor will change
as KSKs are replaced.</t>
<t>Trust anchors for the root zone in particular are published
with intended validity periods, as discussed in
<xref target="retrieval"/>. A validator making use of such
trust anchors also requires an accurate local clock in order
to avoid configuring a local trust anchor which corresponds
to an old key.</t>
<t>Validators should take appropriate steps to ensure that
their local clocks are set with sufficient accuracy, and
in the case where local clocks are set with reference to
external time sources over a network <xref target="RFC5905"/>
that the time information received from those sources is
authentic.</t>
</section>
<section title="Retrieval of Candidate Trust Anchors" anchor="retrieval">
<t>Candidate trust anchors may be retrieved using several
mechanisms. The process of gaining trust in particular
candidate trust anchors before using them is discussed
in <xref target="selection"/>.</t>
<section title="Retrieval of Trust Anchors from Local Sources">
<t>A trust anchor which is packaged with validator software
can never be trusted, since the corresponding root zone
KSK may have rolled since the software was packaged, and
the trust anchor may be derived from a root zone KSK that
was retired due to compromise.</t>
<t>Validators should never use local trust anchors for
bootstrapping.</t>
</section>
<section title="Retrieval of Trust Anchors from the DNS">
<t>The current root zone trust anchor is a hash (in DS RDATA
format) of a member of the root zone apex DNSKEY RRSet
that has the SEP bit set. Such a trust anchor could be
derived from a response to the query ". IN DNSKEY?",
but there is no mechanism available to trust the result:
without an existing, accurate trust anchor the validator
has no means to gauge the authenticity of the response.</t>
<t>Validators should never derive trust anchors from
DNSKEY RRSets obtained from the DNS.</t>
</section>
<section title="Retrieval of Trust Anchors from the Root Zone
KSK Manager">
<t>The Root Zone KSK Manager publishes trust anchors
corresponding to the root zone KSK as described in
<xref target="I-D.jabley-dnssec-trust-anchor"/>.</t>
<t>A full history of previously-published trust anchors,
including the trust anchor recommended for immediate use,
is made available in an XML document at the following
stable URLs:
<list style="symbols">
<t><eref target="http://data.iana.org/root-anchors/root-anchors.xml"/></t>
<t><eref target="https://data.iana.org/root-anchors/root-anchors.xml"/></t>
</list>
Validity periods for each trust anchor packaged in the
root-anchors.xml document are provided as XML attributes,
allowing an appropriate trust anchor for immediate use
to be identified (but see <xref target="timing"/>).</t>
<t>Individual trust anchors are also packaged as X.509
identity certificates, signed by various Certificate
Authorities (CAs). URLs to allow those certificates to
be retrieved are included as optional elements in the XML
document.</t>
<t>For automatic bootstrapping, the recommended approach
is as follows.
<list style="numbers">
<t>Retrieve <eref
target="http://data.iana.org/root-anchors/root-anchors.xml"/></t>
<t>Identify the trust anchors which are valid for current
use, with reference to the current time and date.</t>
<t>Retrieve the corresponding X.509 identity certificates
for the key identified in the previous step, for use
in establishing trust in the retrieved trust anchor
(see <xref target="selection"/>).</t>
</list>
</t>
</section>
</section>
<section title="Establishing Trust in Candidate Trust Anchors"
anchor="selection">
<t>Once a candidate trust anchor has been retrieved, the validator
must establish that it is authentic before it can be used.
This document recommends that this be carried out by checking
the signatures on each of the X.509 identity certificates
retrieved in the previous step until a certificate is found
which matches a CA trust anchor.</t>
<t>This verification phase requires that validators ship with
a useful set of CA trust anchors, and that corresponding
identity certificates are published by the root zone KSK
manager. In some cases validator implementors may decide
to use commercial CA services, perhaps a subset of the
"browser list" that is commonly distributed with web browsers;
alternatively a vendor may instantiate its own CA and make
arrangements with the root zone KSK manager to have the
corresponding identity certificate locations published in
root-anchors.xml.</t>
<t>The CA trust anchors packaged with validators should
have an expected lifetime in excess of the anticipated
life of the validator. As a protection against CA failure,
validators are recommended to ship with more than one CA
trust anchor.</t>
</section>
<section title="Failure to Locate a Valid Trust Anchor">
<t>A validator that has failed to locate a valid trust anchor
may re-try the retrieval and trust establishment phases
indefinitely, but must not perform validation on DNS responses
until a valid trust anchor has been identified.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has no IANA actions.</t>
</section>
<section title="Security Considerations">
<t>This document discusses an approach for automatic configuration
of trust anchors in a DNSSEC validator.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc5011;
&rfc5905;
&I-D.jabley-dnssec-trust-anchor;
<reference anchor="KSK-DPS">
<front>
<title abbrev="Root Zone KSK Operator DPS">DNSSEC Practice
Statement for the Root Zone KSK Operator</title>
<author fullname="Fredrik Ljunggren" initials="F." surname="Ljunggren">
<organization abbrev="Kirei">Kirei AB</organization>
<address>
<postal>
<street>P.O. Box 53204</street>
<city>Goteborg</city>
<code>SE-400 16</code>
<country>Sweden</country>
</postal>
<email>fredrik@kirei.se</email>
</address>
</author>
<author fullname="Tomofumi Okubo" initials="T." surname="Okubo">
<organization abbrev="VeriSign">VeriSign Inc.</organization>
<address>
<postal>
<street>21345 Ridgetop Circle</street>
<city>Dulles</city>
<region>VA</region>
<code>20166-6503</code>
<country>USA</country>
</postal>
<email>tookubo@verisign.com</email>
</address>
</author>
<author fullname="Richard Lamb" initials="R." surname="Lamb">
<organization abbrev="ICANN">Internet Corporation For Assigned Names and
Numbers</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Ray</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<email>richard.lamb@icann.org</email>
</address>
</author>
<author fullname="Jakob Schlyter" initials="J." surname="Schlyter">
<organization abbrev="Kirei">Kirei AB</organization>
<address>
<postal>
<street>P.O. Box 53204</street>
<city>Goteborg</city>
<code>SE-400 16</code>
<country>Sweden</country>
</postal>
<email>jakob@kirei.se</email>
</address>
</author>
<date day="21" month="May" year="2010" />
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
</front>
<format type="TXT"
target="https://www.iana.org/dnssec/icann-dps.txt" />
</reference>
</references>
<section title="Acknowledgements">
<t>This document contains material first discussed at VeriSign
and ICANN during the deployment of DNSSEC in the root zone,
and also draws upon subsequent technical discussion from
public mailing lists. The contributions of all those who
voiced opinions are acknowledged.</t>
</section>
<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>
<section title="Discussion">
<t>This is not a working group document. However, the topics
discussed in this document are consistent with the general
subject area of the DNSOP working group, and discussion
of this document could reasonably take place on the
corresponding mailing list.</t>
</section>
<section title="Change History">
<t>
<list style="hanging">
<t hangText="00">Initial draft.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:26 |