There's a specific provision in the CAA checking algorithm that allows CAs to not even bother checking CAA records if CA operates the nameservers for the domain.
On Monday, 14 October 2019 04:28:19 UTC+2, Clint Wilson wrote: > On Thu, Oct 10, 2019 at 11:32 PM 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 :) > > > > Thank you for the response, insight, and feedback here! Really, really > helpful in clarifying some of the open questions/discussions we've been > having. > > > > > > 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. > > > > Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my > misunderstanding centers around a difference between the Applicant fully > delegating DNS to the CA vs the Applicant only configuring a single CNAME > record? If the Applicant has configured > _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example > then the CA wouldn't be able to use any other <DOMAIN-ID> value to complete > the full lookup to include the TXT record, without the Applicant directly > changing the CNAME value. > > However, if the CA is fully managing this DNS, and therefore able to > independently reconfigure: > _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example > to > _validation.sleevi.example 3600 IN CNAME <EVIL-HACKER-DOMAIN-ID>.ca.example > that's clearly a very different story. > Is it correct to think of these as two different scenarios? In my mind, the > first scenario is the one I'm most interested in. > Even then, I may be oversimplifying things since even in scenario 1 we > could encounter something like this happening (and would want to ensure > it's forbidden): > _validation.sleevi.example 3600 IN CNAME <DOMAIN-ID>.ca.example > <DOMAIN-ID>.ca.example 1 IN CNAME <EVIL-HACKER-DOMAIN-ID>.ca.example > <EVIL-HACKER-DOMAIN-ID>.ca.example 1 IN CNAME <RNDVALUE>.random.ca.example > <RNDVALUE>.random.ca.example 1 IN TXT "{the CA challenge goes here}" > > Would there be a benefit to something like having <DOMAIN-ID> (or > <ACCOUNT-GUID> as discussed further below) published in CAA as well? i.e. > the Applicant publishes a whitelist of valid <ACCOUNT-GUID> values to be > used in this type of validation-delegation-schema? I haven't thought this > through fully, but it seems like it could help with explicitly codifying > the requirements, especially if the CAA record is published at > sleevi.example? > > > > 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. > > > > Agreed with the conclusion, though I can't find a clear statement to this > effect so it remains more of a grey area than I'd like :( > The way I understand it is that currently the BRs are written such that > only when the CA is itself the Applicant can the CA compliantly perform the > 3 flows you outlined above (and there's some stuff about affiliates that > expands that a bit, but not much). But making that even clearer would be > pretty nice. > > > > > > 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. > > > > > It seems like a provision to the effect of "The CA can't modify DNS records > in an Applicant's DNS Zone(s)" is minimally necessary for this to be safe? > That is, even if the Applicant delegates their DNS fully to a CA and points > _validation.sleevi.example to <SLEEVI-ACCOUNT-UNIQUE-ID>.ca.example, > regardless of whether the CA is technically capable of independently doing > so, only the Applicant should be authorized to initiate a change where > _validation.sleevi.example points to, but the CA can modify the DNS records > in the zone(s) it owns (ca.example). The chain of DNS lookups need to > remain transparent and explicit. > The use of <ACCOUNT-GUID> works just as well for us as the <DOMAIN-GUID> > since architecturally a Domain ID is directly tied to an Account ID, so > would be supportive of requiring the <ACCOUNT-GUID> (and doing so seems > like it would fit in better with BR language around Applicants). > > > > 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. > > > > With regards to changes in the BRs, it seems like we need to encapsulate > some specifics to how the DNS delegation can operate and identify what > safety guards are necessary for this be equivalent to current methods. As a > more minor change, would we also need to update the definition of Random > Value so that it can be something used by the CA's Validation system > directly, instead of something only specified to the Applicant? > > > > _______________________________________________ > > 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
