Please return actual domain where TXT record was found when following CNAMEs

[defacto64]

@birgelee,

we understand that Open-MPIC follows CNAMEs, at least when doing DNS queries for TXT records.
This is fine, per se, but we have two concerns:

1. The CABF TLS BRs specify that following CNAMEs is a "may", not a "MUST" (see the definition of Authorization Domain Name), so it would be better if the CA was able to decide whether or not doing so (e.g. by setting some input parameter to the dcv call); this is currently not possible, if we are not mistaken.

2. If, following a CNAME, the expected TXT record is found on a parent domain of the input domain (domain_or_ip_target), then it would be good to know the actual domain where the TXT record was found, because this has some implications. For instance, let's assume that the value of "domain_or_ip_target" is www.somedomain.tld and that, on this domain, there is a CNAME pointing to somedomain.tld. Now, if the TXT record is found on somedomain.tld and the CA is aware of this, then the CA can legitimately insert both domains in the certificate (www.somedomain.tld, somedomain.tld). Otherwise, the CA cannot (must not), since, until proven otherwise, control of the "www" does not imply control of the apex domain. However, the dcv call does not currently returns the domain where the expected TXT record was found (which, because of following CNAMEs, may differ from the value of "domain_or_ip_target").

[birgelee]

Hi @defacto64 . To clarify, ALL DNS operations performed in Open MPIC follow CNAMEs as this is implemented in unbound and is the RFC-recommended way of resolving DNS.

1. currently, configuring the system to not following CNAMEs is not possible currently because we perform all the DNS queries with unbound which properly implements CNAME following per the DNS RFCs. I could probably implement the no CNAME following behavior by ensuring unbound returns any CNAME chain it follows and then invalidating the result if it was derived via a followed CNAME chain. Note that CNAMEs cannot be placed with any other DNS records (at least per the RFC) so if a label has a CNAME and we configure our system not to follow CNAMEs this will always be a failed lookup.

2. I am OK returning the target of the CNAME where the record was found. As I mentioned unbound can be configured to return CNAME chains it follows so we can get the name of the target name where the record was actually found. To be conservative, I personally would probably just run the query again with "domain_or_ip_target" set to the parent domain to confirm the presence of the record at that domain and not just via a CNAME follow.

I don't mind putting these into the project, but for what it's worth, I would probably advise neither of these approaches as I feel they institute network compartmentalization violations. I personally feel DNS is best thought of as providing a mapping between labels and record sets. CNAMEs exist in DNS as a way of facilitating delegations when establishing such mappings. However, I personally think it's best to design applications that have an identical behavior independent of whether a DNS record is obtained via a CNAME or not because CNAMEs are part of the core DNS RFCs and it should really be the obligation of the DNS resolver to follow CNAMEs and return the record sets pointed to. Similar to how the vast majority of linux software will run the same given either a symbolic or a normal file, I think network applications should have the same behavior given a CNAME-retrieved address or one retrieved without a CNAME chain. Obviously this is not a hard and fast rule (e.g., some software behaves differently for symbolic links and DNS resolvers do leak the presence of CNAMEs in their responses), but leaking internals between systems can have complexities down the road.

Note: Following CNAMEs is required for the retrieval of CAA records and I intend for any potential flag added to ignore CNAMEs to only impact DCV and not CAA lookups.

[defacto64]

Hi @birgelee.

Let me clarify that I am not against following CNAMEs, in fact I think it is good practice to follow them, first of all for the reasons you mention. However, I do not see it as mandatory to follow them in the context of checking CAA records, as you say. In the TLS BRs, only compliance with RFC 8659 is required, and this RFC expressly states (in Section 7) that following CNAMEs or DNAMEs is outside the specification and is left to the CA's resolver (and therefore to the CA).

Now, leaving aside my point 1) above, which is arguably of little general interest, the fact remains that a CA may want to know the domain where a certain record was actually found, perhaps following one or more CNAMEs. Since unbound allows this, are you willing to make an update to the caa and dcv calls so to return this information?

[birgelee]

@defacto64 Yes, I am willing to make an update to return the label the final record was found at and if unbound followed a CNAME to get there. I think this is good for transparency and makes a lot of sense (valuable for threat inelegance as well, CNAMEs can leak a lot of key information about an adversary's behavior patterns).

I will say I do not share your view of RFC 8659. The section you are referring to reads:

This document obsoletes [RFC6844]. The most important change is to the "Certification Authority Processing" section (now called "Relevant Resource Record Set" (Section 3), as noted below). [RFC6844] specified an algorithm that performed DNS tree-climbing not only on the FQDN being processed but also on all CNAMEs and DNAMEs encountered along the way. This made the processing algorithm very inefficient when used on FQDNs that utilize many CNAMEs and would have made it difficult for hosting providers to set CAA policies on their own FQDNs without setting potentially unwanted CAA policies on their customers' FQDNs. This document specifies a simplified processing algorithm that only performs tree-climbing on the FQDN being processed, and it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver.

Essentially my interpretation of this text is that RFC6844 had a extremely inefficient CAA search algorithm that required CAs to search up the tree of any CNAMEs or DNAMEs found. Thus, if sub.example.com went to CNAME sub.example.net A CA would have to query CAA in:

sub.example.com

sub.example.net (as dictated by the CNAME)

example.com (as dictated by the primary FQDN tree climb)

example.net (as dictated by the now obsolete RFC6844 CNAME tree climb)

.com (as dictated by the primary FQDN tree climb)

.net (as dictated by the now obsolete RFC6844 CNAME tree climb)

The RFC 8659 algorithm removes the need to query for CAA at example.net and .net in this scenario because the tree climb now only needs to be executed on the FQDN, not the CNAME target.

When the RFC says " it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver" I do not interpret this to mean the recursive resolver can arbitrarily choose to turn off CNAME following. Instead I feel the RFC is saying the "out of the box" CNAME behavior which is already handled by the CA's recursive resolver is now sufficient to handle the CNAME cases in the CAA spec. This eliminates the need for CAs to introduce additional processing logic to handle CNAMEs in CAA lookups which supports the network functions compartmentalization argument I stated previously.

In the section of RFC 8659 immediately before description of the required CAA search algorithm, there is text that reads:

Let CAA(X) be the RRset returned by performing a CAA record query for the FQDN X, according to the lookup algorithm specified in Section 4.3.2 of [RFC1034] (in particular, chasing aliases).

In light of this, I would not implement any CAA checking functionality that did not follow CNAMEs.

Regardless, I like your idea of returning the final name found at and if the result was retrieved via a CNAME for transparency in both CAA and DCV lookups. I will put this in when I get a chance.

[defacto64]

Thank you @birgelee , we look forward to it.

[defacto64]

Hi @birgelee , do you have a forecast of when you will release an update to return the label the final record was found at and if unbound followed a CNAME to get there ?

[birgelee]

Yes, I have this slated for next week.

I can confirm that the dnspython library does have access to the CNAME chain via: dns_response.chaining_result.cnames.

Its mostly a matter of propagating the chain up and putting it into the response details.

To clarify, do you need this on DNS challenges only or HTTP challenges? Additionally, do you need DNAME support and if so do you need the pointer type to be differentiated in the response answer?

[defacto64]

To clarify, do you need this on DNS challenges only or HTTP challenges?

On both, actually.

Additionally, do you need DNAME support and if so do you need the pointer type to be differentiated in the response answer?

We do not need DNAME support.

Thank you @birgelee .

[birgelee]

PRs are out for this in DNS-related validation methods. They just need to get approved. open-mpic/open-mpic-specification#44 #42

Looking over the code, getting the CNAMEs for HTTP challenges is extremely complicated and I feel much less valuable. Particularly because if domain A cnames to domain B, the Host header on the HTTP connection will still show domain A. Thus, an HTTP challenge even in this CNAME scenario cannot validate control of domain B.

On our end, we don't use dnspython for queries for HTTP challenges. Its done with the system dns resolver. This would have to either be over halled to support getting CNAME chains. Also, the HTTP client is allowed to follow 302 redirects (which I believe we do return) so there is actually 2 layers of chaining here.

I am somewhat inclined to say that since the HTTP challenge is at the application layer not the naming layer, only returning the relevant application chain (i.e., the 3xx redirect chain) is sufficient. I also can't justify the scope of the code overall needed to fully get control of the dns queries that are being done during the HTTP challenge. @defacto64 I am curious a bit more for the use case of the CNAME chain on the HTTP challenge. The only possibility I can think of with a reasonable code delta is to get a cname chain from a lookup using dnspython after the main challenge is done using the HTTP library.

[defacto64]

Many thanks, so let's hope that the two PRs will be merged soon.

In the meantime, we will further reflect on our actual need to have this type of functionality also in the case of the HTTP-based method of domain validation, as me may eventually concur with your reasoning.

[birgelee]

the changes for cname chain responses are merged in in core and AWS Lambda. I will probably do a containers version bump coming up.

[defacto64]

Thank you.

[birgelee]

@defacto64 Let me know if the functionality that was added works for you. I am planning to close out this issue shortly unless there is new development on the topic.

[defacto64]

Hi @birgelee Yes, thank you. The functionality that was added works for us.