[cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

Thu Jan 2 09:00:25 MST 2020

Our limit is one or two (I forget which).  It hasn’t caused any problems, and we have most of the largest and most complicated customers.  In practice, people don’t use multiple redirects in the real world because it just slows everything down with no practical benefit.  So there really isn’t a useful argument for a minimum to support, other than perhaps one.

Your second point isn’t valid, though.  There are plenty of places in the BRs where they mandate arbitrarily cutting off a validation process that might otherwise have succeeded if it were allowed to continue.  For example, the various time limits.

-Tim

From: Validation <validation-bounces at cabforum.org> On Behalf Of Corey Bonnell via Validation
Sent: Monday, December 23, 2019 4:18 PM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: Re: [cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

Hi Ryan,

I’d be hesitant to normatively specify a lower bound in this case, for two reasons:

1.	Anti-DoS mechanisms in place by the CA may cause the CA to run afoul of this requirement. For example, suppose that a CA has a timeout on the HTTP-based DV check such that the HTTP request/response must be completed within 30 seconds. If the Applicant’s web server is slow for some reason – either due to a networking issue or something malicious such as a Slowloris-esque attack (but in reverse as the server is malicious) – there’s a chance the CA would not be able to fulfill the requirement to follow the required number of redirects before the timeout elapses. In this scenario, the CA is in the unfortunate situation of violating the BRs by timing out or weakening its security posture by keep HTTP connections open for an exceedingly long time so it can fulfill the minimum # of redirects.
2.	More generically, imposing such a requirement would mean that it’s a BR violation to not carry out the DV check to completion and issue the certificate. I don’t think there’s a precedent in the BRs (or elsewhere) to make the non-issuance of a certificate a compliance issue.

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Monday, December 23, 2019 12:54 PM
To: Corey Bonnell <CBonnell at securetrust.com <mailto:CBonnell at securetrust.com> >; CA/Browser Forum Validation SC List <validation at cabforum.org <mailto:validation at cabforum.org> >
Cc: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >
Subject: Re: [cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

Corey,

I think I agree regarding the limits here. That said, there's an element that I think is useful for Subscriber/Applicants and interoperability here, which may be useful in understanding if there's some minimum amount of redirects that a CA MUST support. Do you think it makes sense to specify this normatively for a floor, with a SHOULD for a ceiling regarding DoS?

CAs MUST be capable of following AT LEAST _xx_ redirects. CAs SHOULD take steps to mitigate the possibility of redirect loops or excessive redirects that may impair service.

On Mon, Dec 23, 2019 at 12:41 PM Corey Bonnell via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

Hello Validation WG,

Thank you Doug for putting this ballot together. This ballot will significantly improve the security properties of HTTP-based domain validation.

I have a concern about the requirement limiting the number of redirects to 10. I could not find any background information on where this requirement came from, and I’m unable to come up with rationale for why this is needed to improve the security properties of the method. If we assume that each redirection is an explicit delegation of authorization, then I don’t see how having 10 such delegations is acceptable but 11 (or more) is not.

If the purpose is to provide guidance to CAs on how to prevent DoS attacks (by following an infinite number of redirects), then I don’t think we need to explicitly mandate a limit, as there are a whole host of other ways to DoS a CA, so this is an incomplete mitigation. CAs need to have more comprehensive DoS countermeasures in place regardless of the requirement.

Unless I’m missing something, I think we should strike that requirement from the ballot.

Thanks,

Corey Bonnell 
Software Architect

 <http://scanmail.trustwave.com/?c=4062&d=5v-A3ql_H051BDcsalddjx4aQBaPdFn1fHeU04y7XA&s=5&u=http%3a%2f%2fwww%2esecuretrust%2ecom%2f> www.securetrust.com

 <https://securetrust.com/resources/library/documents/2019-global-compliance-report/> 2019 Global Compliance Intelligence Report

From: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > On Behalf Of Doug Beattie via Validation
Sent: Thursday, December 19, 2019 10:37 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods

This is where this ballot currently stands.  Are there any comments or can we proceed with this?

I’ve incorporated comments from Ryan and Jacob and taken a first shot a defining a new method for the ACME HTTP method.

==========================

Ballot SC25:  Define New HTTP Domain Validation Methods

Purpose of Ballot: Update to CA/B Forum Baseline Requirements to:

*	Provide additional clarity around how http validation method should be used by creating a new HTTP method and setting a sunset date for method 6
*	Define a method that is specific to the HTTP method defined in section 8.3 of RFC 8555

The following motion has been proposed by Doug Beattie of GlobalSign and endorsed  by Jacob Hoffman-Andrews of Lets Encrypt and Bruce Morton of Entrust.

Motivation:

Provide additional clarity around the Method 6 validation method and to specify a new HTTP method that describes the ACME HTTP method defined in section 8.3 of RFC 8555

---MOTION BEGINS---

Update Section 1.6.1 to remove definition for “Required Website Content” as that define term is no longer being used.

Add a note to the end of 3.2.2.4.6

Note: CAs MUST NOT perform validations using this method after 3 months from IPR review date.  CAs may continue to use domains validated under this method per the applicable certificate data reuse periods.

Add Sections 3.2.2.4.17 and 3.2.2.4.18

3.2.2.4.17 Agreed-Upon Change to Website v2

Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file. 

1.	The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and
2.	the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP return code must be received).

The file containing the Request Token or Random Number: 

1.	MUST be located on the Authorization Domain Name, and
2.	MUST be located under the "/.well-known/pki-validation" directory, and
3.	MUST be retrieved via either the "http" or "https" scheme, and
4.	MUST be accessed over an Authorized Port.

If the CA follows redirects the following apply:

1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx status code).
2.	Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.
3.	CAs MUST NOT follow more than 10 redirects.
4.	Redirects MUST be to resource URLs with either via the "http" or "https" scheme.
5.	Redirects MUST be to resource URLs accessed via Authorized Ports.

If a Random Value is used, then:

1.	The CA MUST provide a Random Value unique to the certificate request.
2.	The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.

**Note:** Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN.  This method is suitable for validating Wildcard Domain Names.

3.2.2.4.18 Agreed-Upon Change to Website - ACME

Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in section 8.3 of RFC 8555. The following are additive requirements to RFC 8555.

The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP return code must be received).

The token (as defined in RFC 855, section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.

If the CA follows redirects:

1.	Redirects MUST be initiated at the HTTP protocol layer (e.g. using a 3xx status code).
2.	Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.
3.	CAs MUST NOT follow more than 10 redirects.
4.	Redirects MUST be to resource URLs with either via the "http" or "https" scheme.
5.	Redirects MUST be to resource URLs accessed via Authorized Ports.

Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN.  This method is suitable for validating Wildcard Domain Names.

---MOTION ENDS---

*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):

A comparison of the changes can be found at: 

 <https://scanmail.trustwave.com/?c=4062&d=5v-A3ql_H051BDcsalddjx4aQBaPdFn1fCaT19zvXQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2f> https://github.com/cabforum/documents/.......

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: November , 2019 9:30am Eastern

End Time: Not before November, 2019 9:30am Eastern

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation <https://scanmail.trustwave.com/?c=4062&d=5v-A3ql_H051BDcsalddjx4aQBaPdFn1fHfH39jvDQ&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200102/ae16139e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10027 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200102/ae16139e/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200102/ae16139e/attachment-0001.p7s>