Discussion on draft ballot to Clarify Authorization Domain Name

[Aaron Gable]

Hi all,

This email is in regards to PR 627, and I encourage folks to read the full text of that draft ballot for context.

One of the biggest issues with the definition of an Authorization Domain Name (ADN) today is that it is unclear whether or not the definition is recursive: if you apply one derivation in the definition (e.g. following a CNAME) can you then subsequently apply other derivations (e.g. following another CNAME, or pruning a label)? The whole goal of PR 627 is to remove all ambiguity from what operations can be performed while deriving an ADN.

This is particularly relevant when it comes to following CNAMEs, because the DNS behaves surprisingly when it comes to CNAME records. If a DNS client issues a query to look up a (for example) TXT record, the resolver MUST process any CNAME records and retry the initial query against the delegated-to name. However, if a DNS client issues a query to look up a CNAME record, no such recursion is done. This means that, if the current ADN definition is not recursive, then the provision that a CA "may use the FQDN returned from a DNS CNAME lookup as the FQDN" means that the CA can only go one layer deep in the CNAME chain when determining the ADN. However, up until now 

This leads to the primary point of ongoing discussion with regards to the PR 627 draft ballot so far: a potential change to how following CNAMEs works. The current text of the ballot makes it unambiguous that (for certain methods that allow following CNAMEs during ADN construction at all) the CA may only perform a single CNAME lookup, i.e. it must use the first CNAME returned, and not follow a whole chain of CNAMEs, per the DNS spec on how CNAME queries work.

On the one hand, allowing CNAME chaining at this top level is very unusual: it requires the CA to implement a whole layer on top of DNS, since no DNS resolver (stub or recursive) will do this CNAME chaining for you. And it seems like it should be unnecessary, since the methods which allow following CNAMEs during ADN derivation (e.g. dns change, email to caa or txt contact) then also follow CNAMEs during actual validation.

On the other hand, disallowing CNAME chaining at this level may be a surprising change from the status quo, as some ecosystem participants believe that the current ADN definition is recursive and therefore allows CNAME chaining. More importantly, it disallows one specific scenario:

- A CDN wants to get a cert for example.org, which is CNAMEd to example.com, which is CNAMEd to example.com.content.cdn.com.
- They want to use a single central solver for ACME DNS-01 challenges, so they CNAME _acme-challenge.example.com.content.cdn.com to acme.cdn.com

If CNAME chaining in ADN construction were disallowed in this scenario, the CDN would either need their customer to CNAME example.org to the CDN directly (so that there's not a chain of CNAMEs prior to reaching the CDN), or they would need their customer to place a CNAME record on _acme-challenge.example.com. Both solutions place higher overhead on the customer/cdn relationship, and neither enforces desirable properties.

Therefore the discussion in the Validation WG meeting this morning pointed towards the conclusion that PR 627 should be updated to allow following multiple CNAMEs during ADN construction, despite this being a weird hack on top of how DNS normally works.

Thanks,

Aaron