draft-ietf-tls-dnssec-chain-extension-02.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 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 rfc7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY rfc7435 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml">
<!ENTITY rfc7633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7633.xml">
<!ENTITY rfc7671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7671.xml">
<!ENTITY rfc7672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7672.xml">
<!ENTITY rfc7901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7901.xml">
]>

<!-- To do: -->
<!--   state machine diagram for the verification section? -->
<!--   raw public keys -->
<!--   pseudocode -->
<!--   test vectors -->



<?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-ietf-tls-dnssec-chain-extension-02"
     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="2017" />
  <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
      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 client and a DNS server. And lastly, it allows a
      TLS client to validate DANE records itself without
      necessarily 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 TLSA records.
    </t>

    <t>
      This mechanism is useful
      for TLS applications that need to address the problems
      described above, typically web browsers or VoIP and
      XMPP applications. 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, or 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="RFC7672">DANE authentication of SMTP
      MTAs</xref> will typically not use this mechanism.
    </t>

    <t>
      The extension described here allows a TLS client to
      request in the client hello message that the DNS authentication
      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 authentication
      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
      and delivering them in an X.509 certificate extension
      <xref target="I-D.agl-dane-serializechain" />. It modifies the approach by using
      wire format DNS records in the serialized data (assuming
      that the data will be prepared and consumed by a DNS-specific
      library), and by using a TLS extension to deliver the data.
    </t>

    <t>
      As described in the <xref target="RFC6698">DANE specification</xref>, this
      procuedure applies to the DANE authentication of X.509
      certificates.  Other credentials may be supported, as
      needed, in the future.
    </t>
    
  </section> <!-- introduction -->

  <section title="DNSSEC Authentication Chain Extension">
    <section title="Protocol, TLS 1.2">

    <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>
      Servers receiving a "dnssec_chain" extension in the
      client hello, and which are capable of being authenticated
      via DANE, MAY return a serialized authentication chain
      in the extended ServerHello message, using the format
      described below.  If a server is unable to return an
      authentication chain, or does not wish to return an
      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>

    <t>
      A client must not be able to force a server to
      perform lookups on arbitrary domain names using this
      mechanism.  Therefore, a server MUST NOT construct
      chains for domain names other than its own.
    </t>

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

    <section title="Protocol, TLS 1.3">

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

      <t>
        Servers receiving a "dnssec_chain" extension in the
        client hello, and which are capable of being authenticated
        via DANE, SHOULD return a serialized authentication chain
        in the Certificate message, using the format
        described below.  The authentication chain will be an
        extension to the certificate_list to which the
        certificate being authenticated belongs.
      </t>

      <t>
        The extension protocol behavior otherwise follows that specified
        for TLS version 1.2.
      </t>

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

    <section title="Raw Public Keys">
      <t>
        <xref target="RFC7250" /> specifies the use of raw
        public keys for both server and client
        authentication in TLS 1.2.  It points out that in
        cases where raw public keys are being used, code for
        certificate path validation is not
        required. However, DANE provides a mechanism for
        securely binding a raw public key to a named entity
        in the DNS, and when using DANE for authentication a
        raw key may be validated using a path chaining back
        to a DNSSEC trust root.  This has the added benefit
        of mitigating an unknown key share attack, as
        described in <xref target="I-D.barnes-dane-uks" />.
      </t>

      <t>The mechanism for encoding DNSSEC authentication
        chains in a TLS extension, as described in this
        document, is not limited to public keys encapsulated
        in PKIX or X.509 containers but MAY be applied to raw
        public keys and other representations, as well.
      </t>
    </section>

    
    <section title="DNSSEC Authentication Chain Data">

      <t>
    The "extension_data" field of the "dnssec_chain" extension 
    MUST contain a DNSSEC Authentication Chain encoded in the
    following form:
      </t>

      <figure>
        <artwork>

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

      <t>
    The AuthenticationChain structure is composed of a sequence of 
    uncompressed wire format DNS resource record sets (RRset) and 
    corresponding signatures (RRsig) records. The record sets and 
    signatures are presented in the order returned by the DNS server
    queried by the TLS server, although they MAY be returned in
    validation order, starting at the 
    target DANE record, followed by the DNSKEY and DS record sets 
    for each intervening DNS zone up to a trust anchor chosen by the
    server, typically the DNS root.
      </t>

      <t>
    This sequence of native DNS wire format records enables easier
    generation of the data structure on the server and easier 
    verification of the data on client by means of existing DNS library
    functions. However this document describes the data structure
    in sufficient detail that implementers if they desire can write
    their own code to do this.
      </t>

      <t>
    Each RRset in the chain is composed of a sequence of wire format
    DNS resource records. The format of the resource record is 
    described in <xref target="RFC1035">RFC 1035</xref>, Section
    3.2.1. The resource records SHOULD be presented in the canonical 
    form and ordering as described in 
    <xref target="RFC4034">RFC 4034</xref>.
      </t>

      <figure>
        <artwork>

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

      <t>
    RRs within the RRset MAY be ordered canonically, by treating
    the RDATA portion of each RR as a left-justified unsigned 
    octet sequence in which the absence of an octet sorts before
    a zero octet.
      </t>

      <t>
    The RRsig record is in DNS wire format as described in 
    <xref target="RFC4034">RFC 4034</xref>, Section 3.1. The 
    signature portion of the RDATA, as described in the same
    section, is the following:
      </t>

      <figure>
        <artwork>

          signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
        </artwork>
      </figure>

      <t>
    where, RRSIG_RDATA is the wire format of the RRSIG RDATA
    fields with the Signer's Name field in canonical form and
    the signature field excluded.
      </t>

      <t>
        The first RRset in the chain MUST contain the DANE records being
        presented.  The subsequent RRsets MUST be a sequence
        of DNSKEY and DS RRsets, starting with a DNSKEY RRset.  Each RRset
        MUST authenticate the preceding RRset:</t>
      <t>

        <list style="symbols">
          <t>A DNSKEY RRset must include the DNSKEY RR containing 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 DNSKEY RRset in the authentication chain, containing 
    the trust anchor may be omitted. If omitted, the client MUST 
    verify that the key tag and owner name in the final RRSIG record 
    correspond to a trust anchor. There may however be reason to 
    include the trust anchor RRset and signature if clients are 
    expected to use RFC5011 compliant key rollover functions inband 
    via the chain data. In that case, they will need to periodically 
    inspect flags (revocation and secure entry point flags) on the 
    trust anchor DNSKEY RRset.
      </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 signatures (the data field
    of the records are omitted here for brevity):
      </t>

      <figure>
        <artwork>

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

      <t>
        Names that are aliased via CNAME and/or DNAME records may involve 
    multiple branches of the DNS tree. In this case the authentication 
    chain structure will be composed of a sequence of these multiple 
    intersecting branches. DNAME chains should omit unsigned CNAME 
    records that may have been synthesized in the response from a DNS 
    resolver. Wildcard DANE records will need to include the wildcard 
    name, and negative proof (i.e. NSEC or NSEC3 records) that 
    no closer name exists MUST be included.
      </t>

      <figure>
        <artwork>

      A CNAME example:

      _443._tcp.www.example.com.   IN   CNAME    ca.example.net.
      ca.example.net.              IN   TLSA     2 0 1 ...

      Here the authentication chain structure is composed of two
      consecutive chains, one for _443._tcp.www.example.com/CNAME 
      and one for ca.example.net/TLSA. The second chain can omit 
      the record sets at the end that overlap with the first.

      TLS DNSSEC chain components:

      _443._tcp.www.example.com. CNAME
      RRSIG(_443._tcp.www.example.com. CNAME)
      example.com. DNSKEY
      RRSIG(example.com. DNSKEY)
      example.com. DS
      RRSIG(example.com. DS)
      com. DNSKEY
      RRSIG(com. DNSKEY)
      com. DS
      RRSIG(com. DS)
      . DNSKEY
      RRSIG(. DNSKEY)

      ca.example.net. TLSA
      RRSIG(ca.example.net. TLSA)
      example.net. DNSKEY
      RRSIG(example.net. DNSKEY)
      example.net. DS
      RRSIG(example.net. DS)
      net. DNSKEY
      RRSIG(net. DNSKEY)
      net. DS
      RRSIG(net. DS)

        </artwork>
      </figure>

      <t>
        Note as well that if a user has a specific TLSA
        record for port 443, and a different wildcard
        covering other ports, attackers MUST NOT be able to
        substitute the wildcard TLSA RRset for the more
        specific one for port 443.  DNSSEC wildcards must
        not be confused with the X.509 wildcards.
      </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 to abort 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 set and its corresponding RRSIG.
      Then traversing the DNS tree upwards towards the trust anchor
      zone (normally the DNS root), for each zone cut, the DNSKEY and
      DS RRsets and their signatures are added. If DNS responses
      messages contain any domain names utilizing name compression
      <xref target="RFC1035"/>, then they must be uncompressed.
    </t>

    <t>
      In the future, proposed DNS protocol enhancements, such as the 
      <xref target="RFC7901"> EDNS Chain Query extension</xref> may 
      offer easy ways to obtain all of the chain data in one transaction
      with an upstream DNSSEC aware recursive server.
    </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 SHOULD cache and reuse it in multiple TLS connection
      handshakes. However, it MUST refresh and rebuild the chain as TTLs
      and signature validity periods dictate. A server implementation 
      could carefully track these parameters and requery component records
      in the chain correspondingly. Alternatively, it could be configured 
      to rebuild the entire 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="RFC7671" />.
    </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 the root trust 
      anchor up to date.  In such cases, the TLS client application 
      could simply reference that as its trust anchor, periodically 
      checking whether it has changed.
    </t>

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


  <section title="Mandating use of this extension" anchor="must_staple">

    <t>
      A TLS server certificate MAY mandate the use of this extension by means 
      of the X.509 TLS Feature Extension described in <xref target="RFC7633" />.
      This X.509 certificate extension, when populated with the dnssec_chain
      TLS extension identifier, indicates to the client that the server must
      deliver the authentication chain when asked to do so. (The X.509 TLS
      Feature Extension is the same mechanism used to deliver other mandatory 
      signals, such as OCSP "must staple" assertions.)
    </t>

  </section>

  <section title="Security Considerations">

    <t> 
      The security considerations of the normatively referenced RFCs 
      (1035, 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to 
      this extension. Since the server is delivering a chain of DNS 
      records and signatures to the client, it MUST 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="RFC5905" />, which are already widely used 
      today. TLS clients MUST support a mechanism to track and rollover 
      the trust anchor key, or be able to avail themselves of a service 
      that does this, 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: Viktor Dukhovni,
      Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus, 
      Rick van Rein,
      Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters.
    </t>

  </section>


</middle>

<back>

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

  <references title="Informative References">
    &rfc5011;
    &rfc5905;
    &rfc7120;
    &rfc7250;
    &rfc7435;
    &rfc7672;
    &rfc7901;
    <?rfc include="reference.I-D.agl-dane-serializechain.xml"?>
    <?rfc include="reference.I-D.draft-barnes-dane-uks-00.xml"?>
  </references>


  <section title="Updates from -01">
    <t>
      <list style="symbols">
        <t>Added TLS 1.3 support</t>
        <t>Added section describing applicability to raw
          public keys</t>
        <t>Softened language about record order</t>
      </list>
    </t>
  </section>
  
  <section title="Updates from -00">
    <t>
      <list style="symbols">
        <t>Edits based on comments from Rick van Rein</t>
        <t>Warning about not overloading X.509 wildcards on
          DNSSEC wildcards (from V. Dukhovny) </t>
        <t>Added MUST include negative proof on
        wildcards (from V. Dukhovny) </t>
        <t>Removed "TODO" on allowing the server to deliver
          only one signature per RRset</t>
        <t>Added additional minor edits suggested by Viktor
        Dukhovny</t>
        
      </list>
    </t>
  </section> <!-- updates -->

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

</back>
</rfc>