On Thu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > My comments are less about middleboxes (TLS-terminating corporate > proxies trusted by the user's browser) and more about unwanted > active MiTM attacks. If the MiTM attacker has obtained WebPKI > (PKIX) certificates for the destination, then this new extension > will not protect the user even when the destination has TLSA > records, because the server can deny their existence (not offer > the extension) without proof. > > What makes this case different is that the naïve mental model > of what it offers is support for DANE-based peer authentication > equivalent to doing the DNSSEC lookups on the client end, but > with DNSSEC tunneled via the server. > > Therefore, some text is probably warranted to disabuse the reader > of such a naïve view. What one gets with this extension, in the > more typical cases in which DANE is not "mandatory", is not > equivalent to enforcing DANE when it is published by the peer. > Rather, what one gets is the ability to use DANE to authenticate > sites that one might not otherwise be able to authenticate (no > shared WebPKI trust-anchor). >
Yes, I agree that some elaboration on this limitation of the protocol is useful. In case you missed it, I do actually document the limitation quite explicitly in Section 8, which I'll excerpt here: "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." But perhaps it needs to feature more prominently in the document rather than being buried in the context of a discussion about mandating the use of this extension. The limitation exists independent of whether a TLS application is trying to mandate things. My suggestion is to move this discussion to the beginning of the Security Considerations section, and then adding some of your elaborating points, including a direct comparison with clients querying DANE records themselves. It might also be worth a brief mention in the Intro section that the protocol lacks authenticated denial and pointing the reader/implementer to the Security Considerations section for more details. Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
