<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 5, 2021 at 10:03 AM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1103801701382149845WordSection1"><p class="MsoNormal">> 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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1103801701382149845WordSection1"><p class="MsoNormal"><u></u></p><p class="MsoNormal">> 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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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 <b>single</b> 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.</div><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1103801701382149845WordSection1"><p class="MsoNormal"><u></u></p><p class="MsoNormal">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. </p></div></div></blockquote><div><br></div><div>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 <b>for every CA in existence</b> - then we would have to move to a world where CAs cannot issue <b>except</b> 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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1103801701382149845WordSection1"><p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>