[cabf_validation] Pre-Ballot discussion on SC25: Define New HTTP Domain Validation Methods
Ryan Sleevi
sleevi at google.com
Thu Jan 2 13:13:04 MST 2020
I don't think we should confuse a lack of imagination for a lack of value
here :)
>From the past validation calls, we discussed some of the ways folks are
presently using DNS records, particularly the TXT/CNAME variety, to
represent 'continuous authorization' for certificate issuance. This was
notably pioneered by Amazon [1], who interestingly enough worked with
DigiCert to develop it [2], so I'm surprised that the connection was not
made.
An easy example of this is a CA that expects to check "
http://somedomain.example/.well-known/pki-validation/something". Users may
have set their server up to automatically rewrite to HTTPS, so the first
redirect is to "
https://somedomain.example/.well-known/pki-validation/something". They
might also have set up their bare name to redirect to www - so the second
redirects to "
https://www.somedomain.example/.well-known/pki-validation/something". This
may then trigger the next stage in processing, which is to redirect to
their cloud provider, "
https://cloudprovider.example/.well-known/pki-validation/cloud-provider-customer-id/something
".
While it may seem like this is a 'convoluted' example, my point in raising
it is the above is entirely CA neutral and would work with any CA that used
Method 6. The cloud provider is given the flexibility to do this via
external redirects, and not just content rewriting, especially when
content-rewriting for something like that can be sensitive and open up its
own set of security issues that the redirect avoids. Of course, knowing
that a given CA only supports one redirect means that nobody can deploy
something like that.
I can understand that some CAs may feel that it's best for customers (or
the cloud providers) to request their CAs support this, and address that
through customer pressure. However, that approach doesn't always lead
itself to progress (see: the lack of CAA adoption while voluntary). That's
why I wanted to raise the suggestion of some 'minimum' number of redirects
to support, to help enable interoperable, CA-neutral solutions to flourish.
[1]
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html
[2] https://www.amazontrust.com/repository/
On Thu, Jan 2, 2020 at 11:00 AM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:
> 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>
> *Sent:* Monday, December 23, 2019 12:54 PM
> *To:* Corey Bonnell <CBonnell at securetrust.com>; CA/Browser Forum
> Validation SC List <validation at cabforum.org>
> *Cc:* Doug Beattie <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> 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
>
>
>
> *[image: cid:image001.png at 01D5B99F.26855AB0]*
> www.securetrust.com
> <http://scanmail.trustwave.com/?c=4062&d=5v-A3ql_H051BDcsalddjx4aQBaPdFn1fHeU04y7XA&s=5&u=http%3a%2f%2fwww%2esecuretrust%2ecom%2f>
>
>
> *2019 Global Compliance Intelligence Report*
> <https://securetrust.com/resources/library/documents/2019-global-compliance-report/>
>
>
>
>
>
> *From:* Validation <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>
> *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://github.com/cabforum/documents/.......
> <https://scanmail.trustwave.com/?c=4062&d=5v-A3ql_H051BDcsalddjx4aQBaPdFn1fCaT19zvXQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2f>
>
>
>
> 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
> 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/152676b5/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/152676b5/attachment-0001.png>
More information about the Validation
mailing list