Change:
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.

Discussion:
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.