[cabfpub] [Ext] .well-known and re-directs

Ryan Sleevi sleevi at google.com
Fri Jul 21 08:04:59 MST 2017


Hi Jeremy,

Apologies for the delay in responding. Would this be a correct summary
of the confusion:

In HTTP, it is a Request/Response protocol. A request is made for a
given resource, and a response is provided. Some responses include the
resource directly requested (e.g. the 200/2xx series), other responses
may indicate the resource has moved (e.g. 304) or is not available
(e.g. 404 or 500). These are valid responses, but they indicate
they're not the resource requested.

The question is whether or not a CA is expected to perform a single
Request/Response in the of retrieving a resource (namely, "the content
of a file or on a web page"), or whether it is allowed to adhere to
the HTTP semantics that indicate how multiple Requests can be made to
ultimately satisfy a resource fetch.

Personally, I'm strongly of the opinion that the Required Website
Content should be obtained via a single Request/Response workflow.
This aligns with at least some of the audit reports I've seen, where
various auditors (whether security or BR) have interpreted this
section as being restrictive to a single Request/Response flow, and
appropriately flagged when a CA follows redirects. This suggests that
there's at least some agreement on this view.

That said, I can also understand and appreciate a view that, by
specifying "content of a file or on a web page", we may have
inadvertently allowed for an interpretation that allows for multiple
Requests/Responses.

When considering the reasonableness of either approach, it does seem
important to consider this: Would we consider it reasonable for a CA
to issue Range Requests for the file or a web page? This is where
multiple requests can be made that, in their sum totality, encompass
the fullness of the file or the web page. Would we allow for partial
range requests (e.g. the CA only requesting say, the first 32 bytes).
Would we expect CAs to detect situations of truncation (e.g. the
content received does not align with the Content-Length) and either
recover from it, reject it, or accept it as valid?

I'm certainly curious others' take, but from an overall security
perspective (and aligning with the security audits of CAs that I've
seen), there seems to be a general belief that a single
Request/Response pair is all that is permitted.

Jacob has taken the view on the rewrite of the scheme, but without
modifying the domain. If a server redirected to ftp://, would we still
consider that Required Website Content? If it redirected to ldap://,
would we still consider that Required Website content?

That said, I haven't heard any arguments that "on the Authorization
Domain" encompasses anything other than the domain itself. At best, a
modification of scheme (and thus, transitively, a modification of the
port used - which needs to be congruent with Authorized Ports) may be
worth discussing, but I would not want to see any scoping beyond that.

In these situations, it seems most advisable to take the restrictive
approach - to disable redirects. The website authentication mechanism
is already substantially less secure than some of our other methods,
and the less we can do to increase that attack surface, the better.

On Fri, Jul 21, 2017 at 10:49 AM, Jeremy Rowley via Public
<public at cabforum.org> wrote:
> Is the lack of additional response agreement that “on the Authorization
> Domain” encompasses both the authorization domain names and redirects from
> an authorization domain name?
>
>
>
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
> via Public
> Sent: Thursday, July 20, 2017 8:37 AM
> To: Jacob Hoffman-Andrews <jsha at letsencrypt.org>; Paul Hoffman
> <paul.hoffman at icann.org>; CA/Browser Forum Public Discussion List
> <public at cabforum.org>
> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
>
>
>
> The BR language states the well-known directory must be “on the
> Authorization Domain Name”.  Whether a re-direct is “on the Authorization
> Domain Name” is questionable.  If following redirects is permitted, the
> language should be updated accordingly.
>
>
>
> Jeremy
>
>
>
>
>
> From: Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org]
> Sent: Wednesday, July 19, 2017 2:54 PM
> To: Paul Hoffman <paul.hoffman at icann.org>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
>
>
>
> I disagree with Paul's interpretation. At Let's Encrypt we have always
> followed HTTP redirects, and consider it an important part of validating by
> HTTP. Consider, for instance, a web site that redirects all "http:" URLs to
> "https:" URLs. If that site were required to inhibit redirects for
> validation requests, that would be harmful to the site's security.
>
>
>
> My interpretation is that RFC 5785 (Well-Known URIs) doesn't need to
> specifically mention redirects, any more than it needs to mention Host
> headers, status codes, or any of the other implementation details of HTTP.
> According to RFC 7231 (HTTP Semantics and Content):
>
>
>
>> The 3xx (Redirection) class of status code indicates that further
>
>> action needs to be taken by the user agent in order to fulfill the
>
>> request.  If a Location header field (Section 7.1.2) is provided, the
>
>> user agent MAY automatically redirect its request to the URI
>
>> referenced by the Location field value, even if the specific status
>
>> code is not understood.
>
>
>
> If it was the intent of RFC 5785 or the Baseline Requirements to rule out
> certain HTTP semantics, that would need to be made explicit. And I think an
> amendment ruling out redirects would be a mistake. For reference, here's the
> relevant BR text:
>
> 3.2.2.4.6 Agreed-Upon Change to Website
>
> Confirming the Applicant’s control over the requested FQDN by confirming one
> of the following under the “/.well-known/pki-validation” directory, or
> another path registered with IANA for the purpose of Domain Validation, on
> the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS
> over an Authorized Port:
>
> The presence of Required Website Content contained in the content of a file
> or on a web page in the form of a meta tag. The entire Required Website
> Content MUST NOT appear in the request used to retrieve the file or web
> page, or
> The presence of the Request Token or Request Value contained in the content
> of a file or on a webpage in the form of a meta tag where the Request Token
> or Random Value MUST NOT appear in the request.
>
> If a Random Value is used, the CA or Delegated Third Party SHALL provide a
> Random Value unique to the certificate request and SHALL not use the Random
> Value after the longer of (i) 30 days or (ii) if the Applicant submitted the
> certificate request, the timeframe permitted for reuse of validated
> information relevant to the certificate (such as in Section 3.3.1 of these
> Guidelines or Section 11.14.3 of the EV Guidelines).
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>


More information about the Public mailing list