> At first I thought that their biggest issue was properly verifying that a domain owner is requesting a certificate (they don't do that, but anyway..).

Why would they? That's not what web PKI standards require. It's not necessary to demonstrate ownership of the domain, only control of the domain.

If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services.

Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois.

> I don't think the industry organizations connected to CAs care enough to put in stringent security practices in place.

This simply isn't true. There's an extremely thorough set of requirements called the "baseline requirements" that every CA must follow. These are written by the CAB forum, which is an industry group comprised of browser/OS vendors and CAs.

I imagine Peter's view may be that the BRs aren't stringent enough and also aren't enforced well enough.

tl;dr it's not impossible and we can delegate requests.

> If only the owner could request a certificate, then many valid use cases would be impossible. i.e. if I use a blogging service to host blog.company.com, they can use Let's Encrypt (or another CA) to manage the cert for me. If domain owners had to manually renew these certs themselves and upload them, HTTPS adoption would be much lower on these types of services.

It's not impossible, and wouldn't even be that difficult, just a few extra steps for LE and the registrar, and one extra step for the domain owner. It would work like this:

Step 1) Domain Owner signs up for a blog on SomeBlogSite.com with their own domain "mycoolrecipes.com" and sets up the DNS record ("mycoolrecipes.com. IN A <sbo IP address here>")

Step 2) SBO wants to gen a cert for mycoolrecipes.com, so they request one from LE.

Step 3) LE goes to the registrar for mycoolrecipes.com and says "Hey, some random blog is trying to get a cert, is this cool? "

Step 4) Registrar sends an e-mail to DO saying, "Hey, is this cool? I know your DNS is pointed at SBO, but I wanted to make sure you actually authorize SBO to handle your security, and not just random network services. Click this link and log in to verify they get the cert."

Step 5) DO logs in to registrar, verifies SBO can have the cert.

Step 6) Registrar notifies LE they can have the cert.

Step 7) LE releases cert to SBO.

This has the effect of 1) removing almost all invisible attacks on cert issuance, because the [delegated] owner has to see and authorize the request, 2) preventing the current need for Certificate Transparency; Registrars could still feed the logs, but CAs wouldn't have to, because the registrar (and domain owner) is the final arbiter, 3) preventing the need for CAA (which doesn't necessarily work anyway and is opt-in), and 4) preventing attacks on DNS from compromising cert issuance.

You can also do this with keys and not e-mails, so that it happens automatically, but only keys authorized by the DO can gen certs. Meaning we have cryptographic proof that only SBO can gen certs for DO, and only with that one CA. Which is way more secure than the current regime. (Again: nobody should be depending on DNS, DNS sucks, and DNS records don't prove domain ownership, nor that you want anything DNS points to at any time to control your security)

> Requiring proof of ownership also wouldn't take into account that DNS hierarchy sometimes extends below what WHOIS can reveal. For instance, a company may delegate department.company.com to some internal sub-group. That sub-group wouldn't be able to manage their own certs if they had to own the registered domain, as shown in whois.

For companies with DNS delegation, registrars can provide more fine-grained delegation features, or companies can integrate a DNS management API to delegate authorization of certs. There are at least two open source DNS management APIs (that work independently of who controls the authoritative DNS server) and can control pre-created zones based on users, groups, and access policies. Registrars can make the request for the FQDN to the main domain and the domain can pass it on as needed. So all of that already exists, it would just need one new API function to handle authorizing certificate issuance.

DNS is a hierarchy, so delegating control like this should be expected. Otherwise, use different top level domains.

And schoen is correct, I don't think the BRs are nearly enough. There are security best practices that are going ignored and would catch a lot of the mistakes perpetrated by integration and operation teams.

This punts all the hard stuff to the registrars. Maybe that makes you feel better, but I think in terms of making the Internet secure that's a step sideways at best.

Hard stuff? All the registrar is doing here is taking a request from a CA and sending it to a user. The user sends back a reply and the registrar passes it along to the CA.

The current regime puts all the "hard stuff" on DNS and BGP (yikes). Instead you could put the "hard stuff" on an HTTP POST over a TLS connection.

The registrar already needed basic account security because otherwise anyone can just compromise the registrar account for a domain, change the authoritative DNS, and own the certs that way. If they do end up increasing their security at all, this is a good thing to protect the domain owners. If they don't increase security at all, we're back where we were before, but without the DNS and BGP vectors.

I'm curious about why this is so, since I've had other discussions about trying to increase registrars' role in certificate verification and issuance, and other people also expressed the idea that registrars weren't really up to the task. But doesn't all DV always essentially treat the registrars' view of domain control as axiomatic? How would it make things worse to involve them more proactively?

When we change the role from passive to active we also significantly change the effect of incompetence and laziness, which are ordinary human traits we should expect to find everywhere and most especially in organisations with no public oversight like the registrars.

Peter's scheme involves a tremendous number of these delegated requests going out every day. Doubtless the vast majority will be legitimate. For all those the lazy (but incompetent) solution is to short circuit between Step 3 and Step 6. Everything appears to work exactly as you'd hope, indeed it's better and more reliable than you might expect. Right up until bad guys realise there's a short circuit.

We know Certificate Authorities, which actually do have oversight and are required to keep proper records and so on, have repeatedly got this sort of thing wrong, short circuiting essential validation steps and not realising because the happy path worked. We should expect it to be _at least as bad_ and probably much worse with registrars.

Hence, as I said, at best a side step.

It's also a huge pile of work. To do this you need to get all the registrars on board, or at least so very many that you can declare the others "unsupported" and cease issuance for their domains without a significant backlash. I would be _astonished_ if anyone can put together a working system, deploy it to all/most registrars and so on in under a decade. I might be on board with a programme of work taking a decade if it was a huge improvement, but as I wrote above it's just a sideways step.

Method 3.2.2.4.1 is dead right? So it seems as though other actors in this space also recognise that "Just ask the registrar" is not a workable solution unless it so happens you are the registrar.

> All these things and more probably affect every CA. LE is just more experimental and new, using less robust infrastructure and technology, and their "growing pains" provide a much more visible and much wider attack surface for abusing PKI.

I think you're also leaving out that LE is more proactive about finding and disclosing problems. Many of the other CAs that encounter similar problems don't write blog posts about them.

Is that supposed to reassure me, or reinforce my point that all of this is a huge mess that's probably trivial to compromise?

That's up to you!

I'm a PKI skeptic who's now working in PKI and my impression is that everything is getting better quickly -- partly thanks to stepped-up scrutiny and enforcement on the browser side, led by Google.

You could look at the "getting better quickly" part and be happy about that, or look at where we started from and be unhappy about that, maybe like several other things in the world.

> all of this is a huge mess that's probably trivial to compromise?

That's a bold claim. I think you should prove it otherwise it's just FUD. By prove it, I mean perform an exploit and documented it. That's the only way things get better.

It's not FUD when you have a list of incidents (https://community.letsencrypt.org/c/incidents) and it's not FUD just because I don't have 0days sitting around. If this is just the incidents from one CA, and assuming this is an example of best effort, there would naturally be many more, and possibly worse, exploits gone unnoticed on the hundreds of other CAs.

Only three of those incidents were described by LE as resulting in misissuance under its CPS:

https://community.letsencrypt.org/t/blocklist-incident-novem... https://community.letsencrypt.org/t/2018-05-18-caa-tag-value... https://community.letsencrypt.org/t/caa-check-incident-decem...

Of these, I believe that none were issued to entities that didn't actually control or operate the sites described by the certificates.

Hmm you may be right in general but this post is about a vulnerability in a specification adopted by LE not a standard designed by LE.

TLS-SNI-01 and ACME were both originally invented by Let's Encrypt, and have still not (quite) been standardized by IETF.