[pas]

The rationale put forward was that validating wildcards is hard, because public suffixes, etc. (So if the server checks a few subdomains randomly, a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain.

Of course, a DNS based validation scheme would work flawlessly for wildcards. (Something like put a TXT at the zone apex on the SOA nameserver.)

But for some reason LE doesn't want to offer wildcards.

[Narkov]

> So if the server checks a few subdomains randomly

Are you suggesting only random checks are completed? Why wouldn't it check all of them?

> a quick attacker can register those subdomains at the provider (eg at a site like github), and then get a cert for the whole domain.

Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)?

[teraflop]

> Why wouldn't it check all of them?

If I request a certificate for "* .github.com", how do you propose that Let's Encrypt check all of the infinitely-many possible subdomains?

> Why would requesting a wildcard for a subdomain (i.e. pas.github.com) give me a cert that works for the root domain (i.e. github.com)?

The issue here is that it's only safe to issue a wildcard certificate to someone who already has full control over all of the domains covered by the wildcard, now and in the future. This is impossible to prove using only an HTTP challenge-response.

For example, let's say an attacker requests a wildcard certificate for "* .github.io". Hypothetically, LE could say: "OK, to prove that you control all possible subdomains, place a particular nonce at http://e9cd20b9c359939c.github.io/.well-known/acme-challenge... Our attacker quickly registers the username "e9cd20b9c359939c" on Github, satisfies the challenge, and gets a cert that allows them to impersonate other Github users.

Alternatively, you could require validation of "github.io" itself, and say that anyone with control over the top-level domain is assumed to be authorized to get wildcard certs as well. But this weakens security for everyone else. For example, Google probably wouldn't be happy if a compromise of their search engine at "google.com" was escalated to a compromise of "accounts.google.com" which handles user sign-in.

These aren't fundamentally unsolvable problems, but there are enough edge cases that the ACME folks decided to postpone wildcards until all the details can be carefully figured out. See https://github.com/letsencrypt/acme-spec/pull/97 for some of the messy details.

[Narkov]

> If I request a certificate for "* .github.com", how do you propose that Let's Encrypt check all of the infinitely-many possible subdomains?

They check you have the authority for github.com and you're done. It is a well understood practice that if you control the parent, you control the children.

> For example, let's say an attacker requests a wildcard certificate for "* .github.io". Hypothetically, LE could say: "OK, to prove that you control all possible subdomains, place a particular nonce at http://e9cd20b9c359939c.github.io/.well-known/acme-challenge.... Our attacker quickly registers the username "e9cd20b9c359939c" on Github, satisfies the challenge, and gets a cert that allows them to impersonate other Github users.

Why would they ask you to verify e9cd.. and not just http://github.io/.well-known/acme-challenge ? How can the opposite be true - i.e. I control github.io but I don't control something-else.github.io ?

I think we can both agree that HTTP challenge-response has flaws and DNS verification is the way forward.

> For example, Google probably wouldn't be happy if a compromise of their search engine at "google.com" was escalated to a compromise of "accounts.google.com" which handles user sign-in.

If I compromise the DNS of google.com, I probably get accounts.google.com and all google.com children in the process.

[teraflop]

> How can the opposite be true - i.e. I control github.io but I don't control something-else.github.io ?

This is easily possible, because control over the host pointed to by the A record for "github.io" says nothing about your level of control over the DNS nameservers.

To use another example (mentioned in the pull request that I linked to above), somebody from MIT described a setup where they issue arbitrary subdomains that may contain periods, such that "x.y.scripts.mit.edu" and "y.scripts.mit.edu" may both be valid hostnames controlled by different users. Currently, there's nothing that the owner of "y" could do to get a certificate for "x.y"; your proposal would break that guarantee.

[throwaway2048]

Lets encrypt supports verification via DNS values.