[cabf_validation] Validation methods used for Wildcards/ADNs

Wed Feb 10 16:59:38 UTC 2021

> No, Corey, as it remains a misstatement of what has been said or the history around this. While I hope this is merely unintentional, it is somewhat surprising, considering you accurately quoted what I said originally - "we've become aware of some CAs having poorly evaluated the security risks in this space" - and instead positioned it as a discussion about "a recently discovered vulnerability".

I quoted your original statement and asked for clarification on what it meant. You then mentioned StartCom/WoSign as being relevant to the topic at hand (despite StartCom/WoSign being a different set of issues), so I followed up to confirm my understanding. It appears that we both actually agree that this is a long-standing practice so I’m not sure how I have mis-stated?

> This is a longstanding issue, and to their credit, a number of CAs have recognized this and the years of discussion, and refused to issue wildcards using these methods. However, we've also seen several CAs begin to think that CAs which take steps to help better secure users, such as not issuing wildcards using less reliable methods, or take the step to ensure unvalidated data, such as in OUs, is not included, that it is a competitive distinction to do the insecure thing, whether it be offering unvalidated data in OUs or promoting the use of wildcards using these methods. It is greatly concerning to us that, rather than recognizing the changes in the industry, such crass and craven CAs see every improvement to security as a chance to heavily market the insecure thing before it becomes forbidden.

ADN != FQDN (which I’ll refer to as “ANEF” validation for brevity) method 18/19 validation is supported by many CAs, so those that do support this are far from the outlier. Additionally, we know that CAs must exhaustively enumerate all domain validation methods that they support in their CPS and will generally also indicate whether the given method supports “wildcard” (i.e., ANEF) validation.  In fact, the CPSs’ of the largest 10 CAs all indicate that for those CAs that list method 18 and/or 19 as an allowed method, they allow validation to be performed at the ADN.

> In the "wrong understanding" method, the ADN that a CA uses is always a subordinate-or-equal to the FQDN being validated, and the ADN can only be composed by removing labels from the FQDN, with the exception of a single underscore label. That is, your description would read as if a CA is authorized to use "_foo.bar.baz.example" to authenticate "baz.example", which is most certainly not the case, because that ADN cannot be constructed from the given FQDN.

Yes, we agree that ADN sub-sub-domains cannot be used to validate a FQDN. However, the allowance for an underscore-prefixed subdomain to validate the parent domain is by the protocol established by method 7 only; this allowance breaks the top-down hierarchical model of DNS. Furthermore, method 7 currently allows for both aliasing of the ADN (via CNAME), but also allows for the ADN to be located at the apex of a sub-zone via NS delegation:

example.com zone:

_my_dcv_label.example.com 3600 IN NS somerandomserver.com.

And if we want to venture into the realm of “not entirely RFC-compliant, but tolerated” there’s also:

*.example.com. 3600 IN NS somerandomserver.com.

Which would allow the DNS administrator of zones served from somerandomserver.com to obtain certificates for example.com.

> So, I think this misguided conclusion may be based on the fact that the choice of an underscore prefix was related to the DNS RFCs, and how such underscore prefixes would not naturally be occurring, particularly in host records (A/AAAA), because they violate the LDH rule. They are a particular subset of labels for which resolving A/AAAA is explicitly a spec violation, and exists to support metadata via other record formats (e.g. TXT). So your comparison of Method 7 to Methods 18/19 is, on its face, grossly inaccurate.

This misses the point I was making. The use of underscore-prefixed subdomains is a consideration that the entire ecosystem must design for as we “pretend” the use of a subordinate DNS label can assert control of the superior node as described above.

> However, you've also made a rather large categorical error in the conclusion, but falsely equating authority to operate a service on a single port as authority to operate the DNS namespace. At best, your argument seems to be "sites should have known better", while completely ignoring the fundamental issue that there is no reasonable basis for belief in the delegation of authority OR in the level of assurance of validation. That is, Methods 18 and 19 for subdomains/wildcards unequivocally do not and cannot provide the same assurance, and your response seems to be at best categorized as "But what if we pretend they did".

At some level, all the domain validation methods involve some level of “pretending” and hand-waving to say that they positively assert control of a given FQDN (and potentially its child nodes). For method 18/19, we currently assert that the ability to serve the Random Value at the well-known URI is proof of control of the ADN and child DNS nodes.

I believe the concern is that pointing to a given machine via an A/AAAA record and serving the Random Value from a well-known URI on that machine is sufficient to assert control of the machine’s FQDN, but not for child nodes of the DNS and there is no way currently for a DNS administrator express that they would like to prohibit such ANEF validation via method 18/19. Additionally, the ANEF allowance for method 18/19 may be surprising for system administrators, which may introduce security issues if their systems do not design for such an allowance. Is this an accurate summary of the concern?

> If the suggestion is to require explicitly-defined, unambiguous delegation via DNS, then I think that's an entirely reasonable path to discuss with respect to how these methods might look. They would, inevitably, be new methods, but the suggestion of "An explicit DNS record that delegates authority to use this HTTP service to perform validations for this domain namespace" certainly would move us closer to having a similar level of assurance, vis-a-vis the domain administrators authorization, while also providing flexibility to reduce the need to update DNS. We've taken this approach before, with respect to CAA extensions for e-mail and phone, so there is precedent.

We (and I imagine many other CAs) would be very supportive of developing such a mechanism so that Applicants can signal in DNS that they wish to allow ANEF validation for methods 18/19. Providing such a mechanism would provide a smooth transition plan for Subscribers while addressing the concerns you raise.

Thanks,

Corey

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, February 5, 2021 11:02 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com>
Cc: CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Validation methods used for Wildcards/ADNs

On Fri, Feb 5, 2021 at 10:03 AM Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> > wrote:

> However, I'm not sure I understand your dismissal of my previous reply, as that's how this message comes across. The fact that several CAs are actively encouraging or promoting their users to use the HTTP-based methods for wildcard certificates, without any acknowledgement of the long-established security risks, is fundamentally concerning. Members have, in the past, objected to when I specifically call out CAs engaged in such practices, but if the request is "name and shame", and members feel it's appropriate, I'm happy to do so.

My previous message was not a dismissal of the concern, but rather a request for clarification as StartCom/WoSign was mentioned but HTTP-based “ADN != FQDN” validation was not relevant to the security issues for that CA. Given your previous responses, it sounds like the motivation for this discussion is not to address a recently discovered vulnerability that has become known regarding HTTP-based domain validation, but instead to continue the long-standing work of this group. Is this an accurate assessment?

No, Corey, as it remains a misstatement of what has been said or the history around this. While I hope this is merely unintentional, it is somewhat surprising, considering you accurately quoted what I said originally - "we've become aware of some CAs having poorly evaluated the security risks in this space" - and instead positioned it as a discussion about "a recently discovered vulnerability".

This is a longstanding issue, and to their credit, a number of CAs have recognized this and the years of discussion, and refused to issue wildcards using these methods. However, we've also seen several CAs begin to think that CAs which take steps to help better secure users, such as not issuing wildcards using less reliable methods, or take the step to ensure unvalidated data, such as in OUs, is not included, that it is a competitive distinction to do the insecure thing, whether it be offering unvalidated data in OUs or promoting the use of wildcards using these methods. It is greatly concerning to us that, rather than recognizing the changes in the industry, such crass and craven CAs see every improvement to security as a chance to heavily market the insecure thing before it becomes forbidden.

That is, understandably, part of the motivation. We've seen a number of CAs take proactive steps towards securing users, in light of these discussions, while at the same time, we've seen CAs see it as an opportunity to do the exact opposite, exposing users to greater risk. That's not acceptable.

> Do you agree that HTTP-based methods fundamentally do not demonstrate control or authorization of subdomains? If you believe they consistently and universally do so, I'm hoping you can articulate how. If the response is "They don't, but maybe that's not an issue", then it might be better if you clearly stated that's your belief.

Each domain validation method describes a delegation stemming from DNS to allow Applicants to assert control of a given domain (and potentially subdomains). These various forms of delegation provide Applicants flexibility so they can perform domain validation and obtain certificates in a variety of configurations. For example, method 18/19 is a delegation of authority from the DNS controller to validate a domain name (and its subdomains) via a A/AAAA record to an HTTP server running under the machine administrator account (since we require privileged ports). This is an issue if a DNS administrator is unaware that a record allows the administrator of the server machine to obtain certificates both for the given domain name and its subdomains.

Method 7 can be performed with no such delegation; the domain validation challenge data is generally stored directly in the DNS zone that contains the FQDN. That intuitively is easier for DNS administrators to understand so that authorization to issue certificates is not inadvertently granted. However, this is not universally the case as method 7 allows for underscore-prefixed subdomains to validate the parent domain. Additionally, there is no requirement that this underscore-prefixed subdomain ADN even be in the same zone as the parent FQDN. In a similar vein to method 18/19, this is a delegation of authority that DNS administrators need to be aware of.

I'm a little concerned with this framing of Method 7, because it suggests a possibly wrong understanding. Alternatively, you may simply be highlighting the known issue for which we still have work to do, with respect to defining explicit prefixes for such delegation.

In the "wrong understanding" method, the ADN that a CA uses is always a subordinate-or-equal to the FQDN being validated, and the ADN can only be composed by removing labels from the FQDN, with the exception of a single underscore label. That is, your description would read as if a CA is authorized to use "_foo.bar.baz.example" to authenticate "baz.example", which is most certainly not the case, because that ADN cannot be constructed from the given FQDN.

It could be that you're highlighting the security risks of the CNAME method introduced by DigiCert causing surprising delegation. If so, we're happy to discuss a ballot to further restrict, in the spirit of ensuring things are consistent.

These methods have long had these security properties, as evidenced by the discussion in various mailing lists and customer-facing documentation provided by many long-standing CAs. 

I hope you can understand and receive it well when I state that this is not an acceptable outcome for users/applicants. That is, this is the same justification that CAs have offered for being able to create arbitrary hostnames. I think for such an outcome to be acceptable - that is, where it's entirely the user's fault if they don't read the documentation for every CA in existence - then we would have to move to a world where CAs cannot issue except when CAA is present, in order to ensure that each user meaningfully accepts the risks of particular CAs and practices. Even then, I cannot guarantee that this would be an acceptable situation, but it would certainly be the minimum required.

It should be obvious that the problem of relying on users to understand the policies of an entity they have no relationship with can affect their security is simply not good for users or websites, however good it may be for the CA, and however tempting it may be for the (few) sites that rely on this. Our consideration is based on the ecosystem and ensuring that users are safe by default. I realize the CA business was created, in many ways, to shift liability so that the CA can blame someone else when things go wrong, as evidenced by the very creation of CP/CPS and guided by the input of the ABA's PAG in developing practices for such documents, but that's not an acceptable state of the world.

Thus, the ecosystem has aligned its operational practices to account for these validation methods. So, to answer your question, my current line of thinking is “They don’t, but maybe that’s not an issue”. Method 7 does utilize the same namespace that is being validated, which seemingly would provide superior security properties over method 18/19, but its provision where a ADN subdomain can validate a parent FQDN makes it similar to the delegation model of method 18/19.

So, I think this misguided conclusion may be based on the fact that the choice of an underscore prefix was related to the DNS RFCs, and how such underscore prefixes would not naturally be occurring, particularly in host records (A/AAAA), because they violate the LDH rule. They are a particular subset of labels for which resolving A/AAAA is explicitly a spec violation, and exists to support metadata via other record formats (e.g. TXT). So your comparison of Method 7 to Methods 18/19 is, on its face, grossly inaccurate.

However, you've also made a rather large categorical error in the conclusion, but falsely equating authority to operate a service on a single port as authority to operate the DNS namespace. At best, your argument seems to be "sites should have known better", while completely ignoring the fundamental issue that there is no reasonable basis for belief in the delegation of authority OR in the level of assurance of validation. That is, Methods 18 and 19 for subdomains/wildcards unequivocally do not and cannot provide the same assurance, and your response seems to be at best categorized as "But what if we pretend they did".

If the suggestion is to require explicitly-defined, unambiguous delegation via DNS, then I think that's an entirely reasonable path to discuss with respect to how these methods might look. They would, inevitably, be new methods, but the suggestion of "An explicit DNS record that delegates authority to use this HTTP service to perform validations for this domain namespace" certainly would move us closer to having a similar level of assurance, vis-a-vis the domain administrators authorization, while also providing flexibility to reduce the need to update DNS. We've taken this approach before, with respect to CAA extensions for e-mail and phone, so there is precedent.

However, we can only make progress on that by recognizing that Method 6/18/19 don't provide the same assurance, and then looking for ways to bolster that assurance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210210/d2692061/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210210/d2692061/attachment-0001.p7s>