I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.
Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty.
At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?
> At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?
I would welcome an authenticated channel to domain registrars, and I would welcome making checking it mandatory for CAs. I think the lack of this is an unfortunate gap, although I don't think we've seen the epidemic of misissuance that you've worried about.
In order to make this happen, it would probably require some coordination between ICANN and the CA/Browser Forum. You can become an Interested Party at the CA/Browser Forum yourself in order to propose this kind of mechanism, or you can find an existing Member or Interested Party to bring it up.
I already participate as an Interested Party and I could bring it up eventually but I'm currently working on certificates for Tor onion services, and I'd rather get that finished before taking on something else.
There may have been previous discussions of this idea in some forum, but I don't know for sure where.
By the way, DNSSEC plus DNS CAA can already allow a domain registrant to use cryptographic means to forbid issuance by unauthorized CAs, and checking this is already mandatory for CAs.
Thanks for pointing that out, I wasn't aware of it.
From Wikipedia: "As of February 2018, Qualys reports that 2.9% of the 150,000 most popular websites use CAA records."
So, about 97% of the most popular websites are currently vulnerable to having valid domain certs generated for their domains if their DNS is compromised, or if the CA doesn't strongly validate DNS responses.
Well, again, DNS has been treated as the source of ground truth for many PKI purposes most of the time for years. It's not new to Let's Encrypt in any way. And it's been a requirement in order to achieve this:
And domain registrants and site operators are extremely heterogeneous in ways that could make cert issuance extremely difficult if we made applicants do something new and manual, especially in the offline world.
On the other hand, I've also written skeptical articles about PKI and worried about the fragility of Internet security. Your concerns aren't misplaced, in that a lot of the stuff we rely on is super-fragile.
But in many ways, it's been getting better over time as CAs' power has been getting more and more circumscribed by new rules and technical mechanisms. We have Baseline Requirements amendments that give CAs less discretion in their operations and require more transparency from them. We have CT, we have CAA, we have must-staple, we have databases that researchers can use to find problems. (For a while we also had HPKP.)
So I'd urge you to take your passion about this issue and work on some more security mechanisms to improve the infrastructure, because there's lots more that can be done.
Also, if you come up with good new deployable mechanisms, Ryan Sleevi will be glad to help you make them mandatory for CAs. :-)
While I appreciate your encouragement, I really dislike the trend of everyone using HTTPS. It's wasteful, it's inconvenient, it's unnecessary, it's overly complex, and it doesn't even provide much real security. People still get hacked, corporations still leak data, the governments of the world continue to spy on our digital emissions. But HTTPS gives everyone a nice fuzzy comfy warm blanket of security to wrap themselves around and forget about the pale reality of life on the internet. (My apologies, I've been really into Russian literature lately)
I don't think anybody would want to implement the kinds of technology and solutions I would provide, because every time I bring them up (in forums like this one, and others), people either ignore them or argue against them, and I have no interest in pushing large boulders up hills.
But I would like to thank you for your work. I appreciate that you all are trying to make things better.
> it's inconvenient, it's unnecessary, it's overly complex, and it doesn't even provide much real security. People still get hacked, corporations still leak data, the governments of the world continue to spy on our digital emissions. But HTTPS gives everyone a nice fuzzy comfy warm blanket of security to wrap themselves around and forget about the pale reality of life on the internet.
Yes, it's inconvenient, and people will still get hacked, but it's also getting easier to do, it _does_ help, and as Snowden showed, encryption really does help deter governments from spying.
I think it's currently unfair to https websites that non-https websites aren't considered insecure.
How do you add that public key to the WHOIS register - Via your domain registrar (and it would have to be updateable/changeable outside of renewal cycles). Who is your DNS provider 90% of the time? Your domain registrar...
