On Wed, 4 Apr 2018, Eric Rescorla wrote:
The motivation for opportunistically using this is to be able to incrementally deploy DANE for HTTPS (and browsers). Without that it won't get deployed at all for HTTPS.I don't see how this is responsive to the concern that this technique will be used for hijacking.
To hijack a DANE TLSA record, an attacker has to take over the DNS domain. Controlling the DNS is equally fatal for the webpki, as you can just ACME a new certificate at that point. So the hijacking case is not made worse at all. But the compromise/coercion of only 1 of 600+ (sub)CA's is actually protected against, making DANE a stronger authentication alternative. Additionally, in the case of forced domain transfer in relation to an ownership dispute being litigated, the DANE based pinning is actually superior to any other kind of pinning, because it gives the (new) domain owner full control to cancel any outstanding long term pins distributed by the old/previous/malicious owner. Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
