[cabf_validation] Validation methods used for Wildcards/ADNs

Wed Feb 3 19:59:57 UTC 2021

Ryan,

There’s a discussion about DNS delegation and the dangers CA could get into if they behave inappropriately here:

https://groups.google.com/g/mozilla.dev.security.policy/c/lT0Dd9XkPwI/m/TRFhrX52AAAJ

If we can come up with some guidance or new method that enables CA/hosting providers/other 3rd parties to publish the random values in the CNAMed destination without introducing massive security problems, then we have a method that we can provide customers to ease the deprecation of the HTTP method.  Basically, for a specific customer account within a specific CA, they can create a subdomain CNAME to a DNS zone controlled by the CA and the domain will never expire for them (for their account), until such time that they migrate from that CA or change accounts.  The CA need to check that the request coming in is from the that account (Applicant) for this to work.  That’s really automated and customer friendly.  This type of method gets us closer to your stated ultimate goal of doing domain validation every week/day/issuance.

Is that all we need to say on this topic?  Unlikely…

Doug

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Wednesday, February 3, 2021 12:51 PM
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 Wed, Feb 3, 2021 at 12:27 PM Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> > wrote:

Hi Ryan,

> First, while this was discussed in the context of our Herndon meeting in early 2018 (specifically, March 2018), you may recall that Google has raised this in the past before then (e.g. in the discussions of StartCom/WoSign validation practices, which were reiterating concerns Google raised to the management list even older than that regarding such validation)

I don’t recall any messages from Root Programs on prohibiting “ADN != FQDN” HTTP-based validation surrounding the StartCom/WoSign incidents [1], as none of the WoSign incidents arose from such allowance. Those incidents arose from failing to prohibit a ADN subdomain from validating a parent FQDN, or allowing validation against HTTP servers running on non-privileged ports, etc. Given this, it would be useful if you could clarify your previous statement that “we've become aware of some CAs having poorly evaluated the security risks in this space” so that everyone has a full understanding of the motivation underlying that statement and how we can address the security concern.

I'll see if I can dig up from the management@ archives, since searching is ... sub-optimal.

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.

However, I cannot help but feel that your line of questioning is trying to dismiss there being any security concerns, including those long-established here in the Forum, even by the validation WG itself. If that's not your intent, I'm hoping you can clarify: 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.

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