5 ms·

> 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 wo

> 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.

schoen 8y ago
I imagine Peter's view may be that the BRs aren't stringent enough and also aren't enforced well enough.
peterwwillis 8y ago
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.
- tialaramex 8y ago
  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.
  - schoen 8y ago
    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?
    - tialaramex 8y ago
      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.

schoen 8y ago

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

peterwwillis 8y ago

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.

tialaramex 8y ago
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.
- schoen 8y ago
  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?
  - tialaramex 8y ago
    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.