i don't remember what the specifics are, but they check from multiple servers distributed around the world
This Tweet was deleted by the Tweet author. Learn more
Conversation
oh, their checks aren't as diverse as i thought but it's a good start i guess letsencrypt.org/2020/02/19/mul
1
They appear to consistently check from 2 perspectives. If there's an attacker with a MITM to both locations, there's currently no way to defend against them getting a Let's Encrypt certificate until they ship the nice accounturi feature. DNSSEC + accounturi gives secure issuance.
This Tweet was deleted by the Tweet author. Learn more
WebPKI is build on poorly verifying domain control based on DNS. WebPKI depends on DNS security. Removing CAs from the picture and using DANE TLSA doesn't require trusting any additional parties but rather reduces trust to the entities in control of naming, who you trust anyway.
1
2
It doesn't move the problem. It eliminates the vast majority of the problem and makes the core root of trust which was still there in the CA system much more clear. You choose your TLD based on who you trust. You still trust them if you use WebPKI. They can get a certificate.
1
1
If you used the .ca TLD, the Canadian government has the control needed to obtain a certificate for your domain without your consent if they choose. Why would you also want to trust tens of thousands of CA and sub-CA entities instead of TLD + registrar? There's also non-IANA DNS.
2
1
Or, similarly, if you use the .app TLD, then Google is in that position of trust. You could also use Google as your domain registrar, avoiding trusting another party. So, you trust IANA + Google and that's it. With WebPKI you trust IANA + Google and tens of thousands of entities.
2
This Tweet was deleted by the Tweet author. Learn more
Open up a terminal and run `drill _443._tcp.grapheneos.org TLSA`. That's the leaf certificate (3) public key (1) sha256 hash (1). If you have DNSSEC validation, you've bootstrapped TLS.
If someone can spoof DNS records, they can just issue certificates via Let's Encrypt, etc.
DANE is complicated if you implement the whole things but browsers could happily implement a subset as a progressive enhancement and ignore the parts they don't want to implement. TTL can be low, since it's not where the security is from. Not TOFU like HPKP and far friendly.
1
It's *widely used* for email servers in Europe already. It works well. Browsers are worried about DNSSEC compatibility but they could restrict DNSSEC validation + TLSA to people using DNS-over-TLS or DNS-over-HTTPS where there's no compatibility problem since it's opaque traffic.
1
1
Show replies