Now that HPKP is removed, browsers should do what they should have done from the beginning by supporting DNSSEC and DANE as a pinning mechanism. No need to support using it as an alternate root of trust. For compatibility can limit it to when DoT or DoH are being used by default.
Conversation
This Tweet was deleted by the Tweet author. Learn more
Replying to
Please don't let them impose inane policies on what sort of DANE records are acceptable for web. Anything should be accepted and completely override webpki if DANE semantics say it does (DANE-EE(3) or -TA(2) vs PKIX-*(0 or 1)).
3
It'd be OK if support in browsers were initially limited to PKIX-TA(0)/PKIX-EE(1). It'd represent progress, and would ward off the DNS-compromise straw-man issue.
Of course with your DNS taken over, the attacker immediately gets an LE certs, and rightly so DV == domain control.
1
But the real issue is that prior to universal deployment of TLSA RRs, how would one know which servers should have them, while in many cases querying from networks where DNSSEC is not available (captive portal, ...)?
Doing this via the chain extension got killed at IETF.
1
So the only way to support DANE in browsers is with DoH/DoT, which are not universally enabled/available. So I don't expect browser support in the near-term.
Whether it is a feature or bug, DANE is also not friendly to enterprise (or nation-state) TLS MiTM proxies.
1
So while DV certs are mostly security theatre, and EV certs a non-solution, the off-line, ad hoc topology provides some measure of flexibility for local policy injection. Browsers inside private networks would still need to trust internal CAs, with the edge proxies using DANE.
1
For HPKP, browsers ignored the pins when the root was a locally added one. Quite horrible, but they could do the same thing for DANE-based pinning if they consider that a hard requirement. Ideally, they'd clearly surface what's happening to the end user though.