<?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 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"> ]> <!-- To do: --> <!-- 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-ietf-tls-dnssec-chain-extension-00" 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="2016" /> <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 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 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, 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> </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> 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 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 MUST contain a DNSSEC Authentication Chain encoded in the following form: </t> <figure> <artwork> opaque AuthenticationChain<0..2^16-1>; </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 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> [TODO: mention that to reduce the size of the chain, the server can deliver exactly one RRsig per RRset, namely the one used to validate the chain as it is built.] </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 are 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 as well as a negative proof (i.e. NSEC or NSEC3 records) that no closer name exists. </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> </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="I-D.ietf-dnsop-edns-client-subnet"> 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, 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; &rfc7435; &rfc7672; <?rfc include="reference.I-D.agl-dane-serializechain.xml"?> <?rfc include="reference.I-D.draft-ietf-dnsop-edns-client-subnet-07.xml"?> </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>