DNS authorization delegation through non-ADN delegated records

[Matthias van de Meent]

Hi,

Today I stumbled upon the acme.sh wiki page regarding DNS alias mode [0], from the discussion on Hacker News [1].

That page details some information that i believe to be of interest. I believe it details some practices that go against the requirements of the DNS Change validation method (s3.2.2.4.7).

The page shows that if you specify a CNAME record on _acme-challenge.my-certificate-domain.example which statically points to _acme-challenge.dynamic-domain.example, then updating only the responses of _acme-challenge.dynamic-domain.example will be enough to get an certificate issued to certificate-domain.example. So, without updating the ADN or updating the DNS records directly under the ADN we have received a certificate for this domain.

I believe that this is problematic practice, as no control has been proven over the Authorization Domain Name. The BR do not mention allowing following CNAME records, but does require the following: "Confirming the Applicant’s control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character" (s3.2.2.4.7).

To me, this sounds like the CNAME record on _acme-challenge.my-certificate-domain.example must immediately contain this random value or request token (i.e. following the CNAME record to a third domain for finding the Random Value or Request Token is not allowed). 

Do note that for determining the ADN following CNAME records is explicitly allowed ("Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. [...]", s1.6.1), but no such explicit exemption to follow CNAME records is made for the 2nd dns domain lookup option (that includes the extra label that starts with a prefix).

Is my understanding that this delegation method is noncompliant correct, or does acme.sh's wiki page detail a valid and correct DNS validation flow?

Kind regards,

Matthias van de Meent

[0] https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode

[1] https://news.ycombinator.com/item?id=28256326

[Jesper Kristensen]

Hi

The BRs don't explicitly specify if following CNAME is allowed or not. Since it is a standard part of DNS, I guess it is allowed. I think it is similar to how the BRs did not specify if following HTTP recirects were allowed until version 1.6.8. The question of following CNAMEs apply to all of the validation methods, not only to the DNS validation method.

In the definition of ADN, the BRs explicitly allows you to follow the CNAME first and then remove the leftmost labels. I think this is in addition to the normal way of using CNAMEs, where you would first remove the leftmost labels and then follow the CNAME.

I think the arguments for or against allowing CNAME is similar to the arguments for or against allowing HTTP redirects. Redirects are allowed, and I think CNAMEs should be too.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAs3B9oj-iFuFE9zhbDZUGLNb95fTVp%2BjGDbQcKU2hWdgtdftQ%40mail.gmail.com.

[Ryan Sleevi]

Hi Matthias,

This is permitted. It is not permitted to point the target of the CNAME to the CA, but other than that, it’s allowed.

The more interesting example of this is Amazon Certificate Manager’s example of this, at 

https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html

Customers create a CNAME pointing to an Amazon domain in order to authorize certificate issuance, even when they do not host their DNS with Amazon. This is an example of a borderline situation, as it would appear the CA is doing the authorization, which the BRs prohibit. However, this works today because Amazon has, for whatever reason (perhaps due to serial misissuances from their own operations), chosen DigiCert to operate a subordinate CA, with Amazon effectively acting as a Super-Root - with DigiCert issuing virtually all ACM certs.

Organizational shell games aside, this particular method has been discussed for years in the CA/Browser Forum, and reflects one of the unsettled open philosophical questions: is the role of the CA that of request authorization (requiring distinct requests for every certificate/key) or domain authorization (validating domains, and allowing unlimited keys to be associated)?

There are clear security benefits to being request/key oriented, but the current allowances for domain validation reuse make it clear the BRs are presently domain authorization. Under today’s model, it’s entirely opaque when a CA may be reusing a cached authorization, and despite mechanisms like CAA, there still aren’t sufficient controls for domain holders, as shown by attacks like BygoneSSL. Techniques like this may prove useful for finding the right balance to reducing, or entirely eliminating, domain validation reuse, requiring persistent validation for every issuance, but allowing the domain holder the flexibility and control to durably delegate this.

Certainly, in the realm where it’s the site operator involved, and the CA is not at all involved in the chain, it’s more cut and dry: it’s presently permitted. 

(With a Google hat) That’s not to say there aren’t security risks involved in this space, which Google has privately flagged to CAs on the CA/B Forum members only management list to draw attention to these risks and expected mitigations in the interim, but we’re working to address these long-term.

On Sun, Aug 22, 2021 at 4:41 AM 'Matthias van de Meent' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Hi,

Today I stumbled upon the acme.sh wiki page regarding DNS alias hismode [0], from the discussion on Hacker News [1].

--