> On Oct 8, 2018, at 8:09 PM, Christopher Wood <[email protected]> > wrote: > > 1. What is the fundamental security issue? What is the purpose of this > extension? > 2. Under what circumstances should DNS records received in the > extension be cached and reused for future use? > 3. Is pinning required? If so, what is pinned, and at what layer(s) > should it be implemented?
1. Some applications that would take advantage of DANE cannot do so because they can't use DNSSEC directly. Either because of last-mile problems or perhaps out of latency considerations (though often the lookups can be made in parallel). 2. The stated purpose of the draft, per its introduction, is to enable such applications to obtain the requisite DNSSEC records in-band from the TLS server, thereby avoid both problems in (1). As noted by Richard Barnes, this even also resolves potential UKS attacks in some protocols, that inherent in DANE without certificate name checks, as with raw public keys, or the advice of RFC7671 Section 5.1 https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-2 <quote> This draft describes a new TLS [RFC5246] [TLS13] extension for transport of a DNS record set serialized with the DNSSEC signatures [RFC4034] needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server 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 [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. [...] </quote> 3. The draft's intended scope is not and should not limited to *just* "green field" applications such as DPRIVE, where use of the extension might be always mandatory, or otherwise based on static local policy for designated peers. 4. Without static client policy, existing applications (e.g. web browsers), can't know a-prior which servers are expected to support the extension and which are not. 5. Absent such knowledge, they're vulnerable to stripping of the extension on first contact, by an attacker able to provide valid WebPKI credentials (unchanged status quo ante for majority of servers). 6. Let's Encrypt certificates are both cost and hassle free. For a an existing application service (not "green field") there's no substantive disincentive to having a WebPKI certificate that ensures interoperability with a majority clients that will at least initially, and perhaps indefinitely, support only WebPKI. 7. If the WebPKI were sufficiently secure to preclude any concerns about (5), then there'd be no need to bother with DANE. Nobody would ever use a BGP MiTM attack to demonstrate domain control (run a server on port 80, respond to an intercepted email to "admin@", forge unsigned DNS replies, ...). 8. If on the other hand, back in the real world, one has legitimate concerns about the security of DV certificate issuance (knowing that compromise of the DNS registrar account used to manage DNSSEC records also necessarily compromises ACME), then one might actually want one's DANE TLSA records to securely restrict the acceptable certificate chains to match the these records in a manner that is not trivially downgraded to the ability to obtain a WebPKI certificate. 9. Not only is the extension subject to stripping by an adversary that subverts DV certificate issuance, thereby eliminating all of its benefits when not enforced by client policy (a-priori static pinning), it still carries costs in the form of needing to keep any TLSA records correct or else risk failure when clients that support the extension see non-matching certificates. The above is discussed in Ben Kaduk's proposed additions to the security considerations back on Jun 1. a. There are other gaps in the document. i. Failure to explain that when the server caches DNS data for multiple responses, it must decrement TTLs when transmitting "aged" data to clients. ii. Failure to adequately explain interactions with virtual hosting iii. Failure to mandate SNI, or to convey the server port in the client extension to deal with DNAT. iv. Pointless ordering constraints on the DNS RRsets, that don't work well when CNAME and DNAME records are involved. So before we discuss remedies, I'd like to hear whether there's substantive disagreement with the above statement of the problem. A discussion of remedies if we don't yet agree on the problem at hand would likely lead to much miscommunication. -- Viktor. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
