With CAA records and a draft extension to CAA [0]. Letsencrypt already supports enough of it in staging. If you enable DNSSEC and set a CAA record like
issue "letsencrypt.org; validationmethods=dns-01"
Then, unless I’m missing something, you’re protected from BGP and other MITM attacks. (Well, you will be once this hits production.) And it’ll be considerably less annoying to work with once the “accounturi” constraint works.
I would go so far as to say that not doing this for a high value site will be irresponsible once this CAA feature becomes stable.
I'm afraid that's unlikely to protect you from BGP attacks.
In theory, the Baseline Requirements require CAs to honor DNSSEC when checking CAA records. However, in practice, there are too many terrible DNS servers, and looking up a CAA record can often fail, for example because the authoritative server just drops any packet containing a CAA query. So CAs are allowed to treat a CAA lookup failure as permission to issue if the domain is not DNSSEC-signed. However, since no off-the-shelf resolver provides an API to check if a domain is DNSSEC-signed, CAs had to roll their own solutions, most of which were wrong and insecure (probably in no small part due to DNSSEC's monstrous complexity). An attacker who can BGP hijack your authoritative DNS servers would be able to get a certificate from one of these CAs.
I created https://caatestsuite.com/ and smoked out many of these bugs in 2017. Maybe the situation has improved since then, but given the difficulty in implementing this check correctly, I'm sure there's at least one CA out there that is doing it wrong, and it only takes one CA to misissue.
It will make BGP attacks considerably harder. It will also make them more like one-off attacks: if you know a vulnerable CA, you can only reliably attack it once like this.
In the long run, I’d love to see something a little more like TLSA so that browsers can at least reject certificates from the wrong CA.
This is the problem: DNSSEC purports to make a difficult attack somewhat more difficult (you say a lot more difficult, I say marginally more difficult) at absolutely staggering enormous global expense.
We can solve the DV misissuance problem directly without forklifting in a new DNS, and the forklift upgrade doesn't even decisively solve the primary problem it's meant to solve.
Do you have a concrete proposal that is both credibly deployable and better than DNSSEC?
DNSSEC is awful in many ways, but it can be deployed incrementally, it's already standardized, and a good chunk of the benefit can be had without changing normal clients at all. I think that "absolutely staggering enormous global expense" is an overstatement.
edit: A major benefit of DNSSEC is that the CA/B forum already requires that CAs use it to check CAA records.
I do have a concrete, credible, deployable proposal: do nothing. DNSSEC is a net negative.
I don't care that it's "standardized". The IETF has standardized a lot of bad stuff. I care that the benefits, such as they are, don't outweigh the costs --- those of a global key escrow system embedded in the DNS, those of the mass deployment of 1990s cryptography, and those of an enormous and expensive disruption to both our networks and, ultimately, our software, much of which will need to be updated to account for the untenable failure mode DNSSEC exhibits today.
Why do I care that CA/B forum requires DNSSEC (when it's enabled) for CAA records? Nobody uses DNSSEC.
Is it your opinion that none of the largest tech companies or financial institutions in the US have good security teams? Or, if, like me, you generally think money buys talent and companies like Google and Facebook and Apple (and, for that matter, Bank of America and Citigroup) have pretty amazing security teams, riddle me this: why have none of them enabled DNSSEC? Are they just too stupid?
Google, Facebook, etc presumably have rather large and competent security teams, and they presumably do things like extensively monitoring CT logs and BGP. And Google's properties nonetheless get hijacked on a semi-regular basis by BGP attacks. (A very small amount of looking suggests that this happened last November.) I'm not aware of anyone using such a BGP attack to get a certificate for a site like YouTube, but I see nothing that prevents it.
I don't actually know why Google doesn't enable DNSSEC on its own properties for this exact reason. They may be relying on the fact that any serious CA will have "google.com" and similar domains in a list of high-risk domains.
(Heck, I can't easily personally monitor BGP for a website even if I wanted to.)
Virtually no company with a reputable security team uses DNSSEC. Not Google. Not Facebook. Not Stripe. Not Braintree. Not Salesforce.com. Not Microsoft. Not Cisco.com. Not IBM. Not Oracle. Not Amazon. Not Github. Not NASDAQ. Not Citigroup. Not Bank of America. Not Schwab. Not Goldman. Not JPMC. Not Boeing. Not Lockheed Martin.
Each of these companies has a huge security team. Not one of them thinks DNSSEC is worth deploying. How do you explain that? Is virtually every infosec team in North America just wrong?
> However, since no off-the-shelf resolver provides an API to check if a domain is DNSSEC-signed, CAs had to roll their own solutions, most of which were wrong and insecure
So fix that problem then. If CAs are not properly checking DNSSEC in violation of the BRs, that's the real problem here. It's not a reason to avoid DNSSEC.
I would go so far as to say that not doing this for a high value site will be irresponsible once this CAA feature becomes stable.
[0] https://tools.ietf.org/html/draft-ietf-acme-caa-06