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
No. DANE-TA and DANE-TE allow TLD operators (and thus anyone who can force them through shady court orders) to completely circumvent TLS without even leaving a trace. PKIX-TA and PKIX-EE would at least force them to leave a trace within the certificate transparency logs.
1
This threat is overstated to the point of being standard anti-DNSSEC FUD, but indeed we do need a DNSSEC analogue of CT. Unlike with webpki CT, it doesn't require trusting CAs to adhere to policy to create such a thing; it can be constructed from observation.
3
No, IMO it cannot. Split horizon configurations are a standard feature in most namesevers.
DNSSEC is an important addition to DNS security, but it's no silver bullet.
1
Anyone who's seen the forged DS has cryptographic proof of its existence. Just need to gamify publication of it.
1
You'd still be able to circumvent that through split horizon DNS. IMO there needs to be a way to enforce that all DS records and proofs of non-existence of DS records at the TLD level be signed by and committed to trustworthy public append-only logs.
1
I don't follow what you're saying you'd be circumventing. The idea is that someone, somewhere sees the forged DS and submits it to an append-only log because doing so is well inventivized. And if you see one nobody else is submitting yet, it's likely forged.
1
However with increased use of centralized DoH services, there is no split horizon (at root/tld level). Cloudflare sees everything and shows the same DS to everyone.
2
In theory, there could be Certificate Transparency logs simply accepting self-signed certificates.
The issue would be convincing a bunch of organizations to run those kinds of logs and coming up with mitigations to deal with spam that would usually be offloaded to the CAs.
Let's Encrypt issues an enormous number of certificates so it places a huge load on the logs they use. It needs to be very reliable, high availability infrastructure. More diversity of logs would be really nice. If it's harder to host, there isn't as much diversity of logs.
Only accept them with valid DANE match. However this is a really inefficient solution. Data volume for CT logs of individual service certs is astronomically larger than just second level DS records.