[cabf_validation] Validation methods used for Wildcards/ADNs

[Ryan Sleevi]

On Fri, Feb 5, 2021 at 10:03 AM Corey Bonnell <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/20210205/b7927aee/attachment.html>