draft-shore-tls-dnssec-chain-extension-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc4330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4330.xml">
<!ENTITY rfc5011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY rfc6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc7120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY rfc7435 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml">
]>

<!-- To do: -->
<!--   check w/Adam Langley about including him as author -->
<!--   verify that "length - 16" is a valid construction -->
<!--   state machine diagram for the verification section? -->
<!--   do we need to do anything about dnae records? -->


<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc docName="draft-shore-tls-dnssec-chain-extension-01"
     ipr="trust200902" category="std">

<front>
  <title abbrev="TLS DNSSEC Chain Extension">
    A DANE Record and DNSSEC Authentication Chain Extension for TLS
  </title>
  <author fullname="Melinda Shore" initials="M"
          surname="Shore">
    
    <organization>No Mountain Software</organization>
    <address>
      <email>melinda.shore@nomountain.net</email>
    </address>
  </author>

  <author fullname="Richard Barnes" initials="R"
          surname="Barnes">
    <organization>Mozilla</organization>
    <address>
      <email>rlb@ipv.sx</email>
    </address>
  </author>

  <author fullname="Shumon Huque" initials="S"
          surname="Huque">
    <organization>Verisign Labs</organization>
    <address>
      <email>shuque@verisign.com</email>
    </address>
  </author>

  <author fullname="Willem Toorop" initials="W"
          surname="Toorop">
    <organization>NLNet Labs</organization>
    <address>
      <email>willem@nlnetlabs.nl</email>
    </address>
  </author>

  <date year="2015" />
  <area>Security</area>
  <workgroup>TLS</workgroup>
  <abstract>
    <t>
      This draft describes a new TLS extension for
      transport of a DNS record set serialized with the DNSSEC
      signatures needed to authenticate that record set.  The
      intent of this proposal is to allow TLS clients to
      perform DANE authentication of a TLS server
      certificate without needing to perform additional DNS
      record lookups.  It will typically not be used for
      general DNSSEC validation of TLS endpoint names.
    </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>
      This draft describes a new <xref target="RFC5246">TLS
      </xref> extension
      for transport of a DNS record set serialized with the
      <xref target="RFC4034">DNSSEC signatures</xref> needed
      to authenticate that record set.  The intent of this
      proposal is to allow TLS clients to perform <xref
      target="RFC6698">DANE authentication</xref> of a TLS
      server certificate without performing perform
      additional DNS record lookups and incurring the
      associated latency penalty. It also provides the
      ability to avoid potential problems with TLS clients
      being unable to look up DANE records because of an
      interfering or broken middlebox on the path between
      the endpoint and a DNS server. And lastly, it allows a
      TLS client to validate DANE records itself without
      needing access to a validating DNS resolver to which
      it has a secure connection.  It will typically not be
      used for general DNSSEC validation of endpoint names,
      but is more appropriate for validation of DANE records
      such as TLSA, SMIMEA, etc.
    </t>

    <t>
      This mechanism is useful
      for TLS applications that need to address the problems
      described above, typically web browsers or VoIP and
      XMPP services. It may not be relevant for many other
      applications. For example, SMTP MTAs are usually
      located in data centers, may tolerate
      extra DNS lookup latency, are on servers where it is
      easier to provision a validating resolver, and are
      less likely to experience traffic interference from
      misconfigured middleboxes. Furthermore, SMTP MTAs usually
      employ <xref target="RFC7435">Opportunistic Security</xref>,
      in which the presence of the DNS TLSA records is used to determine
      whether to enforce an authenticated TLS connection.
      Hence <xref target="DANESMTP">DANE authentication of SMTP
      MTAs</xref> should not use this mechanism.
    </t>

    <t>
      The extension described here allows a TLS client to
      request in the client hello message that the DNS validation 
      chain be returned in the (extended) server hello message.
      If the server is configured for DANE authentication, then
      it performs the appropriate DNS queries, builds the validation
      chain, and returns it to the client. The
      server will usually use a previously cached authentication chain, but
      it will need to rebuild it periodically as described in
      <xref target="sec_caching" />. 
      The client then authenticates the chain using a pre-configured 
      trust anchor.
    </t>

    <t>
      This specification is based on Adam Langley's original
      proposal for serializing DNSSEC authentication chains
      <xref target="AGL" /> and it incorporates his ideas
      and some of his text.  It
      modifies his approach by using DNS wire formats and
      assumes that in implementation, the serialized DNSSEC
      object will be prepared by a DNS-specific module and
      the validation actions on serialized DNSSEC will also
      be carried out by a DNS-specific module.  An appendix
      (empty in the 00 version) provides a Python code
      example of interfacing with a DNS-specific module.
    </t>

  </section> <!-- introduction -->

  <section title="DNSSEC Authentication Chain Extension">
    <section title="Protocol">

    <t>
      A client MAY include an extension of type
      "dnssec_chain" in the (extended) ClientHello.  The
      "extension_data" field of this extension MUST be
      empty.
    </t>

    <t>
      [Placeholder: an upcoming revision of this
      specification will support the ability for the client
      to include a set of unexpired cached records it
      possesses, and correspondingly allow the server to
      return an authentication chain with those records
      omitted.]
    </t>

    <t>
      Servers receiving a "dnssec_chain" extension in the
      client hello SHOULD return a serialized authentication chain
      in the extended ServerHello message, using the format
      described below.  If a server is unable to return a
      authentication chain, or does not wish to return a
      authentication chain, it does not include a dnssec_chain
      extension.  As with all TLS extensions, if the server
      does not support this extension it will not return any
      authentication chain.
    </t>

    </section> <!-- protocol -->

    <section title="DNSSEC Authentication Chain Data">

      <t>
	    The "extension_data" field of the "dnssec_chain"
      extension represents a sequence of DNS resource record
      sets, which provide a chain from the DANE record being provided
      to a trust anchor chosen by the server.  The "extension_data"
      field MUST contain a DNSSEC Authentication Chain encoded in the
      following form:
      </t>

      <figure>
        <artwork>

          struct {
            opaque rrset&lt;0..2^16-1&gt;;
            opaque rrsig&lt;0..2^16-1&gt;;
          } RRset

          RRset AuthenticationChain&lt;0..2^16-1&gt;;
        </artwork>
      </figure>

      <t>
        Each RRset in the authentication chain encodes an RRset along
        with a signature on that RRset.  The "rrsig" field contains
        the RDATA for the RRSIG record, defined in Section 3.1 of
        <xref target="RFC4034">RFC 4034</xref>.  The "rrset" field
        contains the covered resource records, in the format defined
        in Section 3.1.8.1 of <xref target="RFC4034">RFC 4034</xref>:
      </t>

      <figure>
        <artwork>

          signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

          RR(i) = owner | type | class | TTL | RDATA length | RDATA
        </artwork>
      </figure>

      <t>
        The first RRset in the chain MUST contain the DANE records being
        presented.  The subsequent RRsets MUST be an sequence
        of DNSKEY and DS RRsets, starting with a DNSKEY RRset.  Each RRset
        MUST authenticate the preceding RRset:
        <list type="symbols">
          <t>For a DNSKEY RRset, one of the covered DNSKEY RRs MUST be the
            public key used to verify the previous RRset.</t>
          <t>For a DS RRset, the set of key hashes MUST overlap with the
            preceding set of DNSKEY records.</t>
        </list>
      </t>

      <t>
        In addition, a DNSKEY RRset followed by a DS RRset MUST be
        self-signed, in the sense that its RRSIG MUST verify under one
        of the keys in the DNSKEY RRSET.
      </t>

      <t>
        The final RRset in the authentication chain, representing the trust
        anchor, SHOULD be omitted.  In this case, the client MUST verify
        that the key tag and owner name in the final RRSIG record correspond
        to a trust anchor.
      </t>

      <t>For example, for an HTTPS server at
        www.example.com, where there are zone cuts at "com."
        and "example.com.", the AuthenticationChain structure would
	comprise the following RRsets (and their corresponding
	RRSIG signatures):</t>

      <figure>
        <artwork>

          _443._tcp.www.example.com. TLSA
          example.com. DNSKEY
          example.com. DS
          com. DNSKEY
          com. DS
          . DNSKEY
        </artwork>
      </figure>

      <t>
        [Some names involving CNAME and DNAMEs may involve multiple
        branches of the DNS tree. The authors are contemplating
        enhancements to the AuthenticationChain structure to accommodate
        these for a future revision of the draft.]
      </t>

    </section> <!-- authentication chain data -->
  </section> <!-- dnssec authentication chain extension -->

  <section title="Construction of Serialized Authentication Chains">

    <t>
      This section describes a possible procedure for the
      server to use to build the serialized DNSSEC chain.
    </t>

    <t>When the goal is to perform DANE authentication 
       <xref target="RFC6698" /> of the 
       server's X.509 certificate, the DNS record set to be
       serialized is a TLSA record set corresponding to the 
       server's domain name.
    </t>

    <t>
      The domain name of the server MUST be that included in
      the TLS Server Name Indication extension
      <xref target="RFC6066" /> when present. If the Server Name 
      Indication extension is not present, or if the server does not 
      recognize the provided name and wishes to proceed with the handshake 
      rather than aborting the connection, the server uses the
      domain name associated with the server IP address to
      which the connection has been established.
    </t>

    <t>
      The TLSA record to be queried is constructed by prepending
      the _port and _transport labels to the domain name as described
      in <xref target="RFC6698" />, where "port" is the port number
      associated with the TLS server.  The transport is "tcp"
      for TLS servers, and "udp" for DTLS servers.  The port
      number label is the left-most label, followed by the
      transport, followed by the base domain name.
    </t>

    <t>
      The components of the authentication chain are built by
      starting at the target record and its corresponding RRSIG.
      Then traversing the DNS tree upwards towards the trust anchor
      zone (normally the DNS root), for each zone cut, the DS and
      DNSKEY RRsets and their signatures are added.
    </t>
    <t>
      In order to meet these formatting requirements, the server
      must perform some preprocessing on the resource records it
      receives.  It must first compute the uncompressed representation
      of the RRs, removing DNS name compression <xref target="RFC1035"/>,
      if present.  It then extracts the relevant fields from the resource
      records and assembles them into an RRset.
    </t>

  </section> <!-- construction -->


  <section title="Caching and Regeneration of the Authentication Chain"
	   anchor="sec_caching">
    <t>
      DNS records have Time To Live (TTL) parameters, and DNSSEC
      signatures have validity periods (specifically signature expiration
      times). After the TLS server constructs the serialized authentication
      chain, it can cache and reuse it in multiple TLS connection
      handshakes. However, it should keep track of the TTLs and signature
      validity periods, and requery the records and rebuild the authentication
      chain as needed. A server implementation could carefully track
      these parameters and requery the chain correspondingly. Alternatively, 
      it could be configured to rebuild the chain at some predefined periodic
      interval that does not exceed the DNS TTLs or signature validity
      periods of the component records in the chain.
    </t>
  </section>


  <section title="Verification" anchor="sec_verification">

    <t>
      A TLS client making use of this specification, and
      which receives a DNSSEC authentication chain extension
      from a server, SHOULD use this information to perform
      DANE authentication of the server certificate.  In
      order to do this, it uses the mechanism specified by
      the <xref target="RFC4035">DNSSEC protocol</xref>.
      This mechanism is sometimes implemented in a DNSSEC
      validation engine or library.
    </t>

    <!-- TODO: Add a precis of the algorithm here -->

    <t>
      If the authentication chain is 
      correctly verified, the client then performs DANE
      authentication of the server according to the
      <xref target="RFC6698">DANE TLS protocol</xref>, 
      and the additional protocol requirements outlined
      in <xref target="DANEOPS" />.
    </t>

  </section> <!-- verification -->


  <section title="Trust Anchor Maintenance" anchor="sec_trustmaint">

    <t>
      The trust anchor may change periodically, e.g. when the operator
      of the trust anchor zone performs a DNSSEC key rollover. Managed 
      key rollovers typically use a process that can be tracked by 
      verifiers allowing them to automatically update their trust 
      anchors, as described in <xref target="RFC5011" />. TLS clients 
      using this specification are also expected to use such a mechanism 
      to keep their trust anchors updated. Some operating systems may 
      have a system-wide service to maintain and keep up-to-date the 
      root trust anchor.  It may be possible for the TLS client 
      application to simply reference that as its trust anchor,
      periodically checking whether it has changed.
    </t>

  </section> <!-- trust anchor maintenance  -->

  <section title="Security Considerations">

    <t> The security considerations of the normatively
      referenced RFCs (1035, 4034, 4035, 5246, 6066, 6698)
      all pertain to this extension. Since the server is
      delivering a chain of DNS records and signatures to
      the client, it must take care to rebuild the chain
      in accordance with TTL and signature expiration of
      the chain components as described in <xref target="sec_caching" />.
      TLS clients need roughly accurate time in order to properly
      authenticate these signatures. This could be achieved by running
      a time synchronization protocol like NTP
      <xref target="RFC5905" /> or SNTP
      <xref target="RFC4330" />,
      which are already widely used today. TLS clients must
      support a mechanism to track and rollover the trust anchor
      key as described in <xref target="sec_trustmaint" />.
    </t>

  </section>

  <section title="IANA Considerations">

    <t>This extension requires the registration of a new
      value in the TLS ExtensionsType registry.  The value
      requested from IANA is 53. If the draft is adopted by
      the WG, the authors expect to make an early allocation
      request as specified in <xref target="RFC7120"  />.</t>

  </section> <!-- iana considerations -->

  <section title="Acknowledgments">
    <t>
      Many thanks to Adam Langley for laying the groundwork
      for this extension. The original idea is his but our
      acknowledgment in no way implies his endorsement.
      This document also benefited from discussions with and
      review from the following people: Allison Mankin,
      Duane Wessels, Jeff Hodges, Patrick McManus, and Gowri
      Visweswaran.  We are particularly grateful to Viktor
      Dukhovni for his detailed review.
    </t>
  </section>

  <section title="Test Vectors">

    <t>
      [TO BE ADDED LATER. THE ORIGINAL CONTENT WAS OBSOLETE.]
    </t>

  </section> <!-- test vectors -->


</middle>

<back>

  <references title="Normative References">
    &rfc1035;
    &rfc2119;
    &rfc4034;
    &rfc4035;
    &rfc5246;
    &rfc6066;
    &rfc6698;
  </references>

  <references title="Informative References">
    &rfc4330;
    &rfc5011;
    &rfc5905;
    &rfc7120;
    &rfc7435;
    <reference anchor="AGL"
               target="https://tools.ietf.org/id/draft-agl-dane-serializechain-01.txt">
      <front>
        <title>Serializing DNS Records with DNSSEC
        Authentication</title>
        <author fullname="Adam Langley" initials="A"
                surname="Langley" />
        <organization>Google, Inc</organization>
      </front>
    </reference>
    <reference anchor="DANESMTP"
      target="https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19">
      <front>
        <title>SMTP Security via opportunistic DANE TLS</title>
        <author fullname="Viktor Dukhovni" initials="V" surname="Dukhovni" />
        <author fullname="Wes Hardaker" initials="W" surname="Hardaker" />
      </front>
    </reference>
    <reference anchor="DANEOPS"
      target="https://tools.ietf.org/html/draft-ietf-dane-ops">
      <front>
        <title>Updates to and Operational Guidance for the DANE Protocol</title>
        <author fullname="Viktor Dukhovni" initials="V" surname="Dukhovni" />
      </front>
    </reference>
  </references>

  <section title="Pseudocode example">
    <t>[code goes here]</t>
  </section> <!-- pseudocode -->

  <section title="Test vector">
    <t>[data go here]</t>
  </section> <!-- test vector -->

</back>
</rfc>