Many DANE advocates do want it to be available as a full replacement for WebPKI. I'm not suggesting that Chrome should do that. It's usable as either a full replacement or a pinning mechanism. I know Chrome isn't going to drop CT and I'm not proposing that it should be doing it.
Conversation
Replying to
Got it, glad you clarified that.
It doesn't seem as strong as HPKP though, because you're still reliant on trusted third parties with DANE. HPKP let you avoid TTPs entirely, or at least choose the ones you wanted to trust.
1
Replying to
HPKP doesn't work for the first connection or when the pins have expired. DNSSEC + DANE secures the first connection. It relies on DNS as a root of trust, just like WebPKI does for DV. You can choose which TLD operator you want to trust though, instead of trusting all of them.
2
Since TLSA records have a TTL, the browser can choose to store the TLSA record for the entire TTL itself to use it as a pin. This can provide the same kind of trust-on-first-use security as HPKP used to provide, if browsers choose to enforce keeping them around the same way.
1
Replying to
It would also provide all the same foot-gun potential that made people hate HPKP ;-)
1
Replying to
Sites can already brick themselves via DNS without Chrome enforcing TLSA.
TLSA works fine with TTL capped at 1 day, 4 hours, or just left to follow the rules used for other records.
IMO, it's far less of an issue because you can already brick your site via DNS without it.
1
If you set broken DNSSEC records, your site is already bricked via essentially every DoT / DoH provider. Some of them provide a way to flush the caches (such as https://1.1.1.1/purge-cache/ and developers.google.com/speed/public-d). Doing TLSA right is easier than doing DNSSEC right anyway.
1
For TLSA, people using Let's Encrypt can just use the hash of the Let's Encrypt roots.
If they want they want to avoid trusting Let's Encrypt at all they can use the leaf key hash and then for key rotation obtain the new certs with new key, add 2nd record, wait, then deploy it.
1
To simply pin based on the root, it's literally just 1 record. If you want you can add their legacy root, current root, their future ECDSA root and new ones they announce. You don't depend on backups much if you just set TTL to a typical value like 1 hour but you can add them.
1
We have key pins for every single one of our services:
github.com/GrapheneOS/ns1
SSHFP for SSH and TLSA for TLS services (SMTP, SMTPS, IMAPS, HTTPS)
Fully aware almost no web clients enforce it, but many mail servers do, and regardless the maintenance is totally trivial for it.
1
We rotate the keys when we switch to new server instances, which we don't do often. It could be automated for each certificate renewal but at the moment we don't want automated DNS changes and it'd require some work to set up reliable hook-based deployment for certbot.
It would be nice if browsers started using what we're already publishing via DNS records. We used to use HPKP but we only pinned roots and a couple backup leaf pins. 1 hour TTL TLSA record mistakes would be similar to screwing up an A/AAAA record, etc. so it's not scary.
1
1
We still do pinning in our apps similar to what we used to do with HPKP but apps have an escape hatch: can be updated via our app repo and OS updates.
github.com/GrapheneOS/Aud
To do leaf pins there we'd have to set an expiry and do proper rotations. That's hard. DANE is easy.