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

Reply via email to