Change:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.

Discussion:
Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a <del> serialized authentication chain in the Certificate message associated with the end entity certificate being validated, using the format described below.  The authentication chain will be an extension to the certificate_list to which the certificate being authenticated belongs. </del> <ins> serialized authentication chain in the extension block of the Certificate message containing the end entity certificate being validated, using the format described below. </ins> The extension protocol behavior otherwise follows that specified for TLS version 1.2.

The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and <del> corresponding signatures (RRSIG) records. </del> <ins> corresponding signatures (RRSIG) record sets. </ins> This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier

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 <del> RFC1035, Section 3.2.1.  The resource records SHOULD be presented in the canonical form and ordering as described in RFC4034. </del> <ins> RFC1035, Section 3.2.1. </ins> <del> 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. Each RRset in the sequence is followed by its associated RRsig record.  The RRsig record is in DNS wire format as described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> Each RRset in the sequence is followed by its associated RRsig record set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> 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

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.  In order <del> to do this, it uses the mechanism specified by the RFC4035.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </del> <ins> to do this, it uses the mechanism specified by the DNSSEC protocol RFC4035 RFC5155.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </ins> <del> If the authentication chain is correctly verified, the client then performs DANE authentication of the server according to the DANE TLS protocol RFC6698 RFC7671. </del> <ins> Clients MAY cache the server's validated TLS RRset or other validated portions of the chain as an optimization to save signature verification work for future connections.  The period of such caching MUST NOT exceed the TTL associated with those records. </ins> 7.

8. <del> A TLS server certificate MAY mandate the use of this extension by means of the X.509 TLS Feature Extension described in 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.)  Mandating this extension for Raw Public Key authentication (where there are no X.509 certificates) could employ configuration mechanisms external to the TLS protocol. </del> <ins> Green field applications that are designed to always employ this extension, could of course unconditionally mandate its use. If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced.  The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. This protocol currently provides no way for a server to prove that it doesn't have a TLSA record.  Hence absent whitelists, a client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication.  This could be solved by enhancing this protocol to require that servers without TLSA records need to provide a DNSSEC authentication chain that proves this (i.e. the chain includes NSEC or NSEC3 records that demonstrate either the absence of the TLSA record, or the absence of a secure delegation to the associated zone).  Such an enhancement would be impossible to deploy incrementally though since it requires all TLS servers to support this protocol. </ins> 9. <del> 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 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 RFC5905 or SNTP 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 sec_trustmaint. </del> <ins> The security considerations of the normatively referenced RFCs 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 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 RFC5905 or SNTP 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 sec_trustmaint. </ins> 10.

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 <del> McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </del> <ins> McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters. </ins>