Hello, I just want to add that Let's Encrypt also allows for this (at least if I understand what you correctly)
This following is from https://letsencrypt.org/docs/challenge-types/ > Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server. Now you don't delegate it to Let's Encrypt, however you can delegate it to a hosting provider or similar, which seems to be about the same as what AWS is doing if I understand you correctly. - Cynthia Revström On Fri, Oct 11, 2019 at 7:32 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Question, is there any prohibition against demonstration of domain > control > > being delegated to a third party or even the CA itself? I don't think so, > > but figured we've discussed differences in interpretation a lot lately so > > wanted to see if people agreed. > > > > Huge thanks for bringing this up early :) Definitely the example for all > CAs :) > > That said, you probably could have worded better, "demonstration of domain > control being delegated to a third party" is... probably not the best way > of framing ;) > > > > I mean, the obvious issue is the customer.com domain would need to want > > to delegate this domain.com. But if you had a pretty non-technical > person > > operating the DNS, they could set it to the domain.com name and leave > > their DNS settings forever. > > > > This looks allowed under the BRs, but should it be? Or is it like key > > escrow - okay if a reseller does it (but frowned upon). Totally not cool > if > > the CA does it. > > > > This is definitely a good way of looking at it! > > I'm familiar with at least one CA using an approach like this - Amazon > Trust Services, with > https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html > . > There's subtlety here, though, which is why I like how you drew the > comparison to key escrow. > > On first glance, it seems Amazon Trust Services is issuing certificates to > Amazon Web Services, both (through a complex structure) Affiliates, on > behalf of the user. And so it might seem that the user is pointing their > DNS to the CA, and that's how it's working. > > However, when you look through the CCADB disclosures, along with the > certificates actually issued, it's clearer that the user is pointing those > records to Amazon Web Services, but the actual issuing CA is DigiCert (as > disclosed at https://www.amazontrust.com/repository/ ). It's also the case > that, if you look at how things are setup, the domain holder isn't the one > applying for the certificate - it's Amazon Web Services applying for the > certificate (i.e. they are the Applicant, not the domain owner), and AWS > configuring their own DNS records to contain a random value, to demonstrate > to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain. > > It's a really elegant solution, but it turns out it's not a "CA > self-dealing" kind of thing, which would have been useful as an example if > it was already allowed. > > Now let's discuss how this idea could all go wrong, because it teases out a > little why the question of who is Applicant is relevant and important to > understanding. > > Let's imagine that I setup the following (and I'm going to butcher this > pseudo-code, so bear with me) > _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example > <DOMAIN-ID>.ca.example 1 IN CNAME <RNDVALUE>.random.ca.example > <RNDVALUE>.random.ca.example 1 IN TXT "{the CA challenge goes here}" > > Now, whenever the CA receives a request to validate "sleevi.example", they > map that to a domain-id. They then update the CNAME, and the TXT record, to > match the CA-defined challenge value. Then, they issue a TXT record lookup > for _validation.sleevi.example, get the challenge value back, and huzzah, > the cert is authorized! > > But there's a small problem with this. Who was the Applicant requesting > sleevi.example? From the CA's perspective, how does it distinguish me, the > legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the > Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear - > only AWS can do this, and they're who the user delegated to. > > However, if the "party doing this domain dance" is != "the applicant", then > a lot can go wrong here, because they might do the dance for two different > applicants. The easiest example would be if the CA, for every CSR it > received, regardless of the Applicant, it updated the <DOMAIN-ID> for > sleevi.example - at that point, anyone in the world could get a cert for my > domain from that CA, and that would not be the good result. > > This would suggest that we don't want the CA doing it, because the CA is > not the Applicant, and the goal of 3.2.2.4 is to make sure the Applicant > can demonstrate control. > > Another way of looking at this is imagining the following? > - Do we think it's allowed by the BRs for the domain operator to set their > MX to be the CA, so the CA can auto-answer their own emails sent under > 3.2.2.4.4.? > - Do we think it's allowed by the BRs for the domain operator to give the > CA FTP/SSH/file upload access to /.well-known/pki-validation, so that the > CA can place the answer file on the server, and then request it as the CA, > under 3.2.2.4.6? > - Do we think it's allowed by the BRs for the domain owner to set an email > of domain-id@ca.example using 3.2.2.4.13 / 3.2.2.4.14, and allowing the CA > to self-acknowledge that e-mail? > > I seem to recall that there is a provision in the BRs that would prohibit > this, at least in that none of the above (in the CA-controlled example) are > demonstrating the Applicant themselves has control. And we certainly know > from the above example that it could go quite poorly if naively > implemented, so that's probably the right thing. > > That said, the solution Amazon uses here might be a useful solution to > allowing it. Rather than <DOMAIN-ID>, AWS uses something like > <ACCOUNT-UNIQUE-ID>, so that _validation.sleevi.example points to > <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example. In that setup, only the > <SLEEVI-ACCOUNT-UNIQUE-ID> can get new certs for sleevi.example, and any > other accounts would fail, because _validation.sleevi.example wouldn't be > pointing to <EVIL-HACKER-ACCOUNT-UNIQUE-ID>.ca.example, which is the one > the CA would update. But if we're going to go that route, we probably would > minimally want to codify that as the expectation, similar to the intent of > 3.2.2.4.12 of making sure it's actually the same person. > > I realize that I gave this long answer that didn't clearly answer the crux > of your question: do the BRs forbid it? The recap, with all this context, > is: I seem to recall that, in the case where it was not the Applicant > making the change, it was/is forbidden. But I can see good reason to make > it allowed, if we can get the safety guards correct. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
