Just a TXT record.
https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-...
https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-...
Why would you say such a thing?
Tens of millions of certificates have been provisioned using the ACME protocol without issue.
There’s a lot of cryptography behind the scenes that leads up to the TXT record being generated. You can read all about it at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...
If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users.
Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, but you use HTTPS to manage your DNS.
What's really crazy too is it seems like this can't even be avoided. Even if I'm not using Let's Encrypt, if someone owns my DNS, they can use Let's Encrypt to get valid certs for my domain. That's insane.
What am I missing here?
If I "own your DNS" wouldn't I just change them all to an IP space I control anyway? (If that was a requirement).
Unless I'm missing something, requiring "owning the IP space" seems to be an impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I have no way of proving I own the IP (because I don't).
DNS security
As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP.
An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.
An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
If your situation really is that you have unsecured DNS that routinely gets hacked and you just sort of muddle among somehow with users frequently getting phished, malware downloaders, and so on, well, I guess Let's Encrypt doesn't magically solve the trouble you've stepped in.
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.
https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...
This can achieve some of what you want on the negative side, but it's presumably not all the way there.
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.
Yikes.
https://letsencrypt.org/stats/#percent-pageloads
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. :-)
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.
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.
A cloud provider/datacenter controls the IP space in the majority of cases.
If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security (TLS) where the identity of the applicant has been validated by proving some control over a DNS domain"
If this is something that worries you, then you should only trust sites that have Extended Validation certificates.
Every user of the web in the world would have to do this in order to avoid this vulnerability.
But to be honest if your DNS service is compromised, you have bigger problems.
The whole point of TLS is to provide privacy, integrity, and authority. Having a secured connection is pointless if it's a connection to an attacker. Oh, great, nobody can spy on my connection to the NSA.
All DNS is supposed to do is to point you at the server to get your connection from. It isn't supposed to mediate the security of the connection.
This is back to the old chicken-and-egg of public key crypto: public key connections are secure, as long as you provide the initial host key in a secure, out-of-bound method. If an attacker can circumvent this and inject their own initial host key, they can MITM. Hence why PKI exists: to prevent an outside service from defeating the security of the connection. But apparently, DNS can compromise the connection, by allowing attackers to just generate certs willy-nilly if they can guess your GoDaddy account password.