Ryan, Are you recommending that: a) we need a new domain validation method that describes this, or b) those CAs that want to play with fire can go ahead and do that based on their own individual security analysis, or c) we need a clear policy/guideline in the BRs or root program that MUST be followed when the CAs (maybe other entities) are updating DNS with random values?
I'm pretty sure I know the answer (none of the above). -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, October 11, 2019 2:40 PM To: Clint Wilson <cl...@wilsonovi.com> Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: DNS records and delegation On Fri, Oct 11, 2019 at 2:10 PM Clint Wilson <cl...@wilsonovi.com> wrote: > 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. > It's my fault for not being clearer of the example. You can think of <DOMAIN-ID> as an ID computed from the domain being requested - e.g. "sleevi.example" - rather than the account doing the requesting (the Applicant). In that scenario, when Evil Hacker, the Applicant, requests a cert for sleevi.example, the CA doesn't look at the Applicant-ID. They look to see if the domain - e.g. sleevi.example - is one that is signed up to use their service. If so, they modify the records, and now Evil Hacker has access. I tried to clarify this later on, that it's possible to design around; for example, by using <SUBSCRIBER-ID>.ca.example. This is closer to what AWS does. There are /still/ risks with that approach though, in terms of greater centralization of risk. Using the AWS example, if you wanted to get a malicious cert for sleevi.example, you'd either need to compromise my DNS provider, my DNS registrar, or my AWS account. Using the <SUBSCRIBER-ID> example, with the CA hosting, you'd either need to compromise my DNS provider, my DNS registrar, or... well, the CA's systems. Allowing the CA to do this sort of flow creates real challenges, because they're the only ones that can issue certs. For example, the CA could refuse to use that TXT method for anyone who doesn't point to them (e.g. who uses AWS instead of the CA). It might seem odd to suggest that CAs might refuse issuance, but we see it all the time. After all, the whole reason we have so many trusted CAs is because there are a number (particularly the European CAs) that want to refuse issuance on grounds of who is applying or how they're applying (e.g. ETSI EN 319 411-et-al forbidding automation entirely!). So we know CAs can try to lock folks in, and we also know that CAs' incentives, around user/account security, are not necessarily the same as might exist with a third-party provider like AWS. I realize that seems like I'm suggesting a lot of ill-intent. I'm simply trying to threat-model both the systemic weaknesses and the economic incentives. If we allow the CAs to do this, it seems like we'd need even stronger rules regarding Subscriber/CA authentication and identification, and that... would likely be controversial and complex, to say the least ;) 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? > That's functionally what AWS is doing - it's using <ACCOUNT-GUID> instead of <DOMAIN-ID> as the binding, and pushing that in the hop. > 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. > Yeah, that's my recollection/understanding as well, and agree, we can make it clearer that this is/should be prohibited, and then discuss how we can go allowing it. > 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). > Just to clarify: the risk scenario I was trying to describe is where <DOMAIN-ID> is *not* linked to <ACCOUNT-ID>. If you don't have that, all bets are off. So it seems that, before saying it's copacetic, we need language to make clear the Right Way and the Dangerous Way, at least with respect to CAs. > 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? > Thanks, that's another good point about why prohibited - the Random Value is specified to the Applicant, which is true in the AWS case (AWS is the Applicant, DigiCert is the CA), but not true in the CA-hosting-the-CNAME case. But yeah, I agree with the overall approach: In order to say this is safe and good, we'd need to specify a clear and precise algorithm that made sure the relevant safe guards were in place. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
