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