<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->

<!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 rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3339 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.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 rfc4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4398 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml">
<!ENTITY rfc5011 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5905 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY rfc5908 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5908.xml">
<!ENTITY I-D.jabley-dnsop-validator-bootstrap PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jabley-dnsop-validator-bootstrap.xml">
<!ENTITY I-D.jabley-dnssec-trust-anchor PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jabley-dnssec-trust-anchor.xml">
<!ENTITY I-D.jabley-dnsop-dns-flush PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jabley-dnsop-dns-flush.xml">
<!ENTITY I-D.ietf-dhc-option-guidelines PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-option-guidelines.xml">
]>

<rfc category="std"
     docName="draft-mglt-homenet-dnssec-validator-dhc-options-02.txt"
     ipr="trust200902">
  <front>
    <title abbrev="DNSSEC Validator DHCP Options">DNSSEC Validators DHCP Options</title>
    <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>38 rue du General Leclerc</street>
          <city>92794 Issy-les-Moulineaux Cedex 9</city>
          <country>France</country>
        </postal>
        <phone>+33 1 45 29 60 52</phone>
        <email>mglt.ietf@gmail.com</email>
      </address>
    </author>

    <!--
    <author fullname="Ralf Weber" initials="R." surname="Weber">
      <organization>Nominum</organization>
      <address>
        <postal>
          <street>2000 Seaport Blvd #400</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>US</country>
        </postal>
        <phone/>
        <facsimile/>
        <email>ralf.weber@nominum.com</email>
        <uri>http://www.nominum.com</uri>
      </address>
    </author>
    -->

    <!-- <date month="February" year="2013"/>-->
    <date/>
    <area>INTERNET</area>

    <workgroup>HOMENET</workgroup>

    <abstract>
    <t>DNSSEC provides data integrity and authentication for DNSSEC validators. However, without valid trust anchor(s) and an acceptable value for the current time, DNSSEC validation cannot be performed. As a result, there are multiple cases where DNSSEC validation MUST NOT be performed. In addition, this list of exceptions is expected to become larger over time.</t>

<t>Considering an increasing number of cases where DNSSEC is disabled adds complexity to the DNSSEC validator implementations and increases the vectors that disable security.</t>

    <t>This document assumes that DNSSEC adoption by end devices requires that end devices MUST be able to support a DNSSEC validation always set. This MUST be valid today as well as in the future.</t> 

    <t> This document describes DHCP Options to provision the DHCP Client with valid trust anchors and time so DNSSEC validation can be performed.</t>
    </abstract>
  </front>

  <middle>

    <section title="Requirements notation">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>
    </section>
    <section title="Introduction">

    <t>DNSSEC <xref target="RFC4033"/>, <xref target="RFC4034"/>, <xref target="RFC4035"/> adds data authentication and integrity checks to DNS <xref target="RFC1034"/>, <xref target="RFC1035"/>. For signature validation, DNSSEC requires a trust anchor such as the Key Signing Key (KSK) of the Root Zone or any other zone. Without a trust anchor, DNSSEC validation cannot be performed. In addition KSKs and signatures are valid for a given period of time. As a result, DNSSEC validation cannot be performed if time shifting is to large.</t>

    <t>This document considers DHCP DNSSEC Trust Anchor Option and DHCP Time Option to provision a device with trusted KSKs and current time. Although our priority is to provide the Root Zone KSK, we also consider the case other trusted KSK MAY be provided, for example, if a Zone does not provide secure delegation, or to mitigate badly configured DNSSEC zones (like TLDs zones).</t>

    <t>The main motivation for these DHCP Options is that DHCP enabled devices have DNSSEC validation always set and do not need to perform DNS resolution without DNSSEC validation. In fact, enabling DNS with no validation represents a potential way to remove security and MAY be used by attackers. Similarly, DNSSEC configuration implemented in the end users device, MAY not consider future cases and MAY introduce vulnerabilities. DHCP Options prevent this as long as the relationship between DHCP Client and DHCP Server is trusted.</t>

    <t>This document assumes that the channel between the DHCP Client and the DHCP Server is trusted and secured with DHCP mechanisms described in <xref target="RFC3315"/>, or IPsec <xref target="RFC4301"/>.</t>
 
    </section>

    <section title="Threat Model">

    <t>This document addresses the case of a device configured with DNSSEC validation set that is plugged in, gets connectivity (using DHCP for example), but fails DNSSEC resolutions because its trust anchor KSK is not valid anymore or its local time is not valid.</t>

    <t>This threat mainly addresses devices that can be switched off for a long period of time or devices that MAY be off-shelves for a long time before being plugged in. CPEs as well as any homenet devices are concerned by this use case.</t>

    <t>This threat also addresses DNSSEC emergency key roll over operations. Devices that have cached the out-of-date KSK will not be able to check the signatures until the TTL has expired on all caches.</t>

   <t>This document proposes DHCP Options that provide the necessary parameters to perform DNSSEC validation. These Options MUST be used on a trusted network over a trusted channel between the DHCP Client and the DHCP Server. These options MAY be used in conjunction of additional mechanisms.</t>

    <section title="Motivations for providing DNSSEC Trust Anchor">

    <t>The first motivation for providing trusted KSKs is to provide automatic configuration of devices to enable DNSSEC validation. This avoids validator initial KSK provisioning issue as well as KSK roll over issues.</t>

    <t>A validator MAY not be able to perform signature check with an authenticated KSK because:
    <list hangIndent="6" style="hanging">
        <t hangText="- 1)">It does not have a trust anchor (like the Root Zone KSK)</t>
        <t hangText="- 2)">The KSK MAY have been authenticated, stored or cached with an expiration date valid but is not valid anymore. This MAY happen in the case of an emergency key roll over, if the device has been offline during the key roll over, or if the key roll over is not performed as described in <xref target="DPS-KSK"/>, <xref target="RFC5011"/>.</t>
        <t hangText="- 3)">The chain of trust MAY have been broken. This can happen to non Root Zone KSK only and MAY not involve the responsibility of the owner of the zone. The deeper the Zone is in the hierarchy, the more likely this happens.</t>
        <t hangText="- 4)">A DNSSEC zone MAY have been badly signed or a KSK MAY have been badly generated. The DNSSEC MAY be correct, but DNSSEC validator MAY keep for a long time the badly generated KSK, ZSK...</t>
    </list>
    </t>

    <t>The goal of the DHCP DNSSEC Trust Anchor Option is to provide these validators trusted anchors like the Root Zone KSK, as well as other KSKs (TLDs...) so the validator has the proper KSKs to perform DNSSEC validation.</t>

   <t>Most documents are currently focused on the Root Zone KSK for which recommendations and alternative mechanisms have been described. <xref target="I-D.jabley-dnsop-validator-bootstrap"/> provides guide lines on how to retrieve and select DNSSEC Trust Anchors. Section 5.3 and <xref target="I-D.jabley-dnssec-trust-anchor"/> describes mechanisms to retrieve securely the Root Zone KSK relying on TLS security. It suggests to use insecure DNS resolution to set HTTPS connections. Using HTTPS requires downloading the keyDigest id (key-label) from https://data.iana.org/root-anchors/root-anchors.xml, followed by an HTTPS request at https://data.iana.org/root-anchors/key-label.crt to get the whole certificate.</t>

    <t>The key advantages of the DHCP DNSSEC Trust Anchor Option described in this document are that we extend the mechanism to any KSK, and validators can set DNSSEC validation for all DNS queries. However, we do not see any contradiction between recommendations provided by <xref target="I-D.jabley-dnsop-validator-bootstrap"/> and <xref target="I-D.jabley-dnssec-trust-anchor"/> and believe the principle described in these documents SHOULD be applied by the validators. Note also that DHCP DNSSEC Trust Anchor Option only benefits to validators that are configured via DHCP.</t>

   <t>To recover from a DNSSEC failure and remove a particular data from cache, <xref target="I-D.jabley-dnsop-dns-flush"/> suggests to use a NOTIFY message between Authoritative Servers and Resolvers. This mechanism is set between Recursive Server and Authoritative Servers with a specific trusted relationship. This is probably a selection of TLDs. This document, does not address the DNSSEC failure over Recursive Servers, but addresses more specifically DHCP configured devices. These are typically CPEs or End Users. We believe that configuring and restarting DNSSEC validators with DHCP Option, is an easier way to cope with this issue. First the trust relation between DHCP Server already exists, we do not need additional trusted channel between Authoritative Servers or eventually the Recursive Servers. Then basic implementations of stub resolvers, in CPE or desktops may not address NOTIFY message.</t>  

    </section>

    
    <section title="Motivations for providing Time">
      
    <t>KSKs and signatures are always associated to an expiration time. As a result, DNSSEC validation requires that the validator knows the current time.</t>

    <t>A number of mechanisms exists like <xref target="TLSDATE"/> or <xref target="RFC5905"/> for setting the time of the device. In addition, <xref target="RFC5908"/> provides a Network Time Protocol (NTP) Server Option for DHCP. The DHCP Time Option described in this document differs from <xref target="RFC5908"/> as it provides an estimation of the current time, instead of providing the NTP servers location information. The time value provided by the DHCP Time Option should be used only if previously mentioned mechanisms are either not implemented on the device or are unavailable. One of the reason MAY be that you MAY need valid DNS(SEC) resolution to use these protocols. The time provided by the DHCP Time Option does not have the accuracy of NTP and SHOULD be considered as a best effort value. <xref target="I-D.jabley-dnsop-validator-bootstrap"/> also recommends that when time has not been verified by the validator, the signature validation SHOULD be done with time off.</t>
 
    <t>The key advantage of the DHCP Time Option is that it makes possible to have DNSSEC validation always set. It limits the possible DNSSEC validation variants which potentially expose the device to disable DNSSEC validations. Note also that DHCP Time Option only benefits to validators that are configured via DHCP.</t>
    </section>

    </section>
    <section title="Terminology">

    </section>

   
    <section title="DHCP DNSSEC Trust Anchor Options">

    <t>This section describes two options:
        <list style="hanging" hangIndent="6">
            <t hangText="- DHCP DNSSEC KSK Trust Anchor Options:"> carries the KSK RRset as described in <xref target="RFC1035"/> with a DNSKEY RDATA as described in <xref target="RFC4033"/>. This data is not integrity protected, nor it can be authenticated. Such data SHOULD be trusted over a trusted DHCP channel.</t>
            <t hangText="- DHCP DNSSEC CERT Trust Anchor Options:"> Carries a certificate encoded as described in <xref target="RFC4398"/>. The advantage of the Certificate is that is enables authentication of the received information by a trusted party. For example, CPE providers MAY provide a trusted certification authority. Unlike DNSSEC key roll over, the CPE provider controls the key roll over of the certification authority it provides.</t>
        </list>

    </t>

        <section title="DHCP DNSSEC KSK RR Trust Anchor Options">

        <t>The DHCP DNSSEC KSK Trust Anchor Option provides the RRset as mentioned in the DNS(SEC) Zone. In other words, it carries the RR as defined in Section 3.2. of <xref target="RFC1035"/> and a RDATA DNSKEY as defined in Section 2.1 of <xref target="RFC4033"/>. As the RR has a variable length, the DHCP DNSSEC KSK Trust Anchor Options follows the recommendation format of Section 5.9 of <xref target="I-D.ietf-dhc-option-guidelines"/>.</t>

     <figure>
        <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          option-code          |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                             KSK RR                            .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 1: DHCP DNSSEC KSK Trust Anchor Options
                  Payload Description
        ]]></artwork>
      </figure>
      <t>       
        <list style="hanging" hangIndent="6">
            <t hangText="- option-code:">OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR</t> 
            <t hangText="- option-len:">An unsigned integer giving the length of the KSK RR field in this option in octets</t> 
        </list>
      </t>

        </section>
    
        <section title="DHCP DNSSEC KSK CERT Trust Anchor Options">
    
        <t>The DHCP DNSSEC CERT Trust Anchor Option provides a certificate. The CERT RR is described in <xref target="RFC4398"/>. Note that only the RDATA associated to the CERT is present in the DHCP Option. As the RR has a variable length, the DHCP DNSSEC KSK CERT Trust Anchor Options follows the recommendation format of Section 5.9 of <xref target="I-D.ietf-dhc-option-guidelines"/>.</t>

     <figure>
        <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          option-code          |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                        KSK CERT RDATA                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 2: DHCP DNSSEC CERT Trust Anchor Options
                  Payload Description
        ]]></artwork>
      </figure>
      <t>       
        <list style="hanging" hangIndent="6">
            <t hangText="- option-code:">OPTION_DNSSEC_CERT_TRUST_ANCHOR</t> 
            <t hangText="- option-len:">An unsigned integer giving the length of the KSK RR field in this option in octets</t> 
        </list>
      </t>
        
      <t>The X.509 <xref target="RFC5280"/> certificate MUST have a keyUsage set to digitalSignature (0) and nonRepudiation (1). Subject Alternative Name DNS name indicates the name of the zone.</t>  
      <t>In order to be compliant with the certificate of the Root Zone described <xref target="I-D.jabley-dnssec-trust-anchor"/>. The CERT for a KSK SHOULD have a Common Name (CN) with the string "'Zone-FQDN' Zone KSK" followed by the time and date of key generation in the format specified in <xref target="RFC3339"/>. 'Zone-FQDN' is the name of the zone and SHOULD be the same as the one mentioned in Subject Alternative Name. The resourceRecord Attribute SHOULD be set with the DS RRset.</t>
        </section>
    </section> 

    

    <section title="DHCP Time Option">
   
    <t>The DHCP DNSSEC Time Option is used by the DHCP Server to indicate the Time to the DHCP Client. The Time is provided in a string format as specified in <xref target="RFC3339"/> and in <xref target="I-D.ietf-dhc-option-guidelines"/> Section  5.8.</t>
     <figure>
        <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          option-code          |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                        TXT Time Format                        .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 2: DHCP Time Options
                  Payload Description
        ]]></artwork>
      </figure>
      <t>       
        <list style="hanging" hangIndent="6">
            <t hangText="- option-code:">OPTION_TIME</t> 
            <t hangText="- option-len:">A string representing the Time</t> 
        </list>
      </t>
        
    </section> 





    <section title="DHCP Client Behavior">
   
    <t>DHCP DNSSEC KSK Trust Anchor Option, DHCP DNSSEC CERT Trust Anchor Option or DHCP Time Option described in this document are intended for DNSSEC validation. If a connected device is not performing DNSSEC validation, it MUST NOT send a DHCP an Option Request DHCP Option (ORO) <xref target="RFC3315"></xref> for any of these options, and MUST ignore all these options if provided by the DHCP Server.</t>

    <t>The DHCP sends a DHCP ORO for one or multiple options described in the document. Motivations for sending this Option Request DHCP Option is out of scope of the document. It could be a device switched off for a long time, a device that cannot validate the DNSSEC responses.</t>

    <t>A channel is considered trusted if 1) the DHCP Server is trusted and authenticated and 2) exchanged data between the DHCP Client and the DHCP Server is integrity protected. IPsec <xref target="RFC4301"/>, for example, MAY be used to establish a secure channel. </t>

   <t>Over a trusted channel, the DHCP Client that performs DNSSEC validation MAY send an ORO for any of the DHCP DNSSEC KSK Trust Anchor Option, the DHCP DNSSEC CERT Trust Anchor Option or the DHCP Time Option to a DHCP Server.</t>

    <t>Over a trusted channel, the DHCP Client that performs DNSSEC validation SHOULD consider the DHCP DNSSEC KSK Trust Anchor Option, the DHCP DNSSEC CERT Trust Anchor Option or the DHCP Time Option sent  by the DHCP Server.</t>

    <t>Over a non trusted channel, the DHCP Client MAY only send ORO for a DHCP DNSSEC CERT Trust Anchor Option. This option is the only one that MAY be considered by the DHCP Client if sent by the DHCP Server. If the DHCP Client does not trust the signer of the certificate, the option MUST be ignored.</t>

    <t>When a DHCP DNSSEC KSK Trust Anchor Option or a DHCP DNSSEC CERT Trust Anchor Option is accepted by the DHCP Client, it MUST remove overwrite old values for the KSK with the new one.</t>

    <t>When a DHCP Time Option is accepted by the DHCP Client, it MUST check the difference between its clock and the time provided by the Option. It SHOULD overwrite its clock value only if the difference is too large.</t>

    <t>In any other case, ORO requests MUST NOT be sent by the DHCP Client, and options received by the DHCP Server MUST NOT be considered by the DHCP Client. The remaining of the section details when the options MUST NOT be requested by the DHCP Client and MUST be ignored by the DHCP Client when received by the DHCP Server.</t>  


    <t>The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust Anchor Option, a DHCP DNSSEC CERT Trust Anchor Option or a DHCP Time Option to a DHCP Server that is either not trusted or not authenticated.</t>

    <t>All DHCP DNSSEC KSK Trust Anchor Option, a DHCP DNSSEC CERT Trust Anchor Option or a DHCP Time Option received from DHCP Server that is not authenticated or that is not trusted MUST be ignored by the DHCP Client.</t>

    <t>The DHCP Client MUST NOT send an ORO for a DHCP DNSSEC KSK Trust Anchor Option or a DHCP Time Option to a trusted DHCP Server over an untrusted channel. A DHCP DNSSEC CERT Trust Anchor Option MAY be requested over an untrusted channel since the certificate is signed and thus can be authenticated. A DHCP DNSSEC CERT Trust Anchor Option signed by an untrusted authority MUST be ignored by the DHCP Client.</t>

    <t>All DHCP DNSSEC KSK Trust Anchor Option or a DHCP Time Option received from DHCP Server over a channel that is not trusted MUST be ignored by the DHCP Client.</t>
    </section> 

    <section title="DHCP Server Behavior">

    <t>The DHCP Server SHOULD properly answer with the requested options in the ORO, even if the DHCP Server does not consider the channel with DHCP Client as trusted.</t>

    <t>The DHCP Server MAY also provide DHCP DNSSEC KSK Trust Anchor Option, DHCP DNSSEC CERT Trust Anchor Option or DHCP Time Option without being requested by the DHCP Client. This could for example prevent failures not detected by the DHCP Client.</t>
    </section>    
  
    <section title="DHCP Relay Agent Behavior">
    <t>The DHCP Options described in the document do not impact the Relay Agent.</t>
    </section>    



    <section title="IANA Considerations">

    <t>The DHCP options detailed in this document is:
        <list style="hanging" hangIndent="6">
            <t hangText="- OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR:">TBD</t>
            <t hangText="- OPTION_DNSSEC_KSK_CERT_TRUST_ANCHOR:">TBD</t>
            <t hangText="- OPTION_TIME:">TBD</t>
        </list>
    </t>
    </section>

    <section title="Security Considerations">
      <t>Security has been discussed in the "DHCP Client Behavior Section". As information contained in the payloads are use to enable signature validation, these pieces of information MUST be considered only when issued by a trusted party, and when integrity protection is provided.</t>
    </section>

    <section title="Acknowledgment">
    <t>Bringing DNSSEC in Home Networks discussion has started during the IETF87 in Berlin with Ted Lemon, Ralph Weber, Normen Kowalewski, and Mikael Abrahamsson. An email discussion has also been initiated by Jim Gettys with among others, helpful remarks from Paul Wouters, Joe Abley, Michael Ridchardson.</t> 
    </section>
  </middle>

  <back>
    <references title="Normative References">
        &rfc1034;
        &rfc1035;
        &rfc2119;
        &rfc3315;
        &rfc3339;
        &rfc4033;
        &rfc4034;
        &rfc4035;
        &rfc4301;
        &rfc4398;
        &rfc5011;
        &rfc5280;
        &rfc5905;
        &rfc5908;
    </references>

    <references title="Informational References">
        &I-D.jabley-dnsop-validator-bootstrap;
        &I-D.jabley-dnssec-trust-anchor;
        &I-D.jabley-dnsop-dns-flush;
        &I-D.ietf-dhc-option-guidelines;
        <reference anchor="DPS-KSK">
        <front>
            <title>DNSSEC Practice Statement for the Root Zone KSK Operation</title>
            <author initials="F" surname="Ljunggren" fullname="F. Ljunggren"/>
            <author initials="T" surname="Okubo" fullname="T. Okubo"/>
            <author initials="R" surname="Lamb" fullname="R. Lamb"/>
            <author initials="J" surname="Schlyter" fullname="J. Schlyter"/>
            <date year="2010" />
        </front>
        <seriesInfo name="" value="Root DNSSEC Design Team" />
        <seriesInfo name="URL:" value="http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt" />
      </reference>

        <reference anchor="TLSDATE">
        <front>
            <title>tlsdate: secure parasitic rdate replacement</title>
            <author initials="IO" surname="error" fullname="IO. Error"/>
            <date year="2013" />
        </front>
        <seriesInfo name="URL:" value="https://github.com/ioerror/tlsdate" />
      </reference>

    </references>

    <section title="Document Change Log">
      <t>[RFC Editor: This section is to be removed before publication]</t>


      <t>-00: First version published.</t>
    </section>
  </back>
</rfc>
