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.


TLS mailing list

Reply via email to