At the moment, Let's Encrypt primarily issues certificates based on insecure, authenticated HTTP-based validation of domain control.
They validate DNSSEC but the HTTP-01 method by itself is insecure and the DNS-01 method requires giving servers DNS API access which isn't good.
Conversation
community.letsencrypt.org/t/acme-caa-val (accounturi) is a feature currently available on their staging server providing a solution.
The accounturi feature allows you to pin the ECDSA-based renewal account to provide a secure chain of trust from DNSSEC for issuing certificates via Let's Encrypt.
1
7
This feature isn't deployed on their production server yet.
It's implemented for all of the GrapheneOS domains/subdomains now and we've tested across all with the Let's Encrypt staging server.
Of course, you still trust every CA to validate CAA/DNSSEC and not be compromised.
1
6
Our public keys for all our TLS-based services are pinned across all our services via DANE TLSA records.
If clients validated DNSSEC and enforced a tiny subset of DANE (public key pins for leaf certificates) it would solve the problem of needing to trust all CAs. Fix it already.
2
10
Replying to
For these purposes, what do you think of the argument that DNSSEC is inappropriate for the SSL trust model because DNS is in many countries in the direct control of the government and the government is many of those same countries a potential threat actor?
1
Replying to
TLS trust model depends on DNS. DV certificates are issued to anyone who controls DNS. OV and EV certificates aren't useful. Browsers never displayed an indicator for OV and EV didn't accomplish much so they stripped away the indicators for that too. There's basically just DV.
1
2
Let's Encrypt and other public CAs will give you a certificate to anyone who controls DNS from their perspective. If someone hijacks controls of your DNS or simply spoofs it (if you don't have DNSSEC) they can simply obtain valid Let's Encrypt certificates to use for your domain.
1
WebPKI does nothing to proactively defend against DNS hijacking or spoofing. The only mechanism that's offered is reactive defence via Certificate Transparency (CT).
CT currently depends on Expect-CT header pinning because you can spoof dates prior to Chrome requiring it.
1
Certificate Transparency isn't trivial to use. You need to track all certificates actually issued by your servers. Otherwise, how do you figure out which are your Let's Encrypt certificates vs. someone else who hijacked DNS and issued certificates for your domain? Non-trivial.
So, with the necessary infrastructure for it, CT allows you to receive an alert that a certificate was created which wasn't issued by your actual server. Revocation doesn't really work well, especially when you didn't issue the certificate, so that's just even more of a mess.
1
At that point, the attack has happened, and you're trying to clean up the aftermath. If they're still in a position to hijack DNS, they can just keep getting new certificates. There's nothing you can do about it beyond watching it with CT (once it's truly mandatory, at least).
1
Show replies
Rather trivial: any time a cert is issued with a different pubkey from original/previous it's sus.
1
I deal with it as part of dealing with TLSA records. I do that manually though, so I just add the public keys to arrays of valid ones for each server. In practice, I rotate the keys when moving to a new dedicated server or VPS to avoid trusting that the last wasn't compromised.
1
1
Show replies