[cabf_validation] Proposed replacement for Method 6

[Wayne Thayer]

Doug,

Thanks for getting this ballot moving! My comments are intended to clarify
the proposed language:

* The wording of requirements 2 and 3 may be confusing. I'd suggest
changing that section to sentences as follows:
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. The
entire Request Token or Random Value MUST NOT appear in the request used to
retrieve the file, and
the CA must receive a successful HTTP response from the request (meaning a
2xx HTTP return codes must be received).

* Change the last bullet to "Must be to an Authorized Port" otherwise the
redirect may be to an unauthorized port.

* Consistently capitalize HTTP and HTTPS.

I think we want to keep the notes. I recall that there is an error in the
Request Token note that should also be corrected:
https://cabforum.org/pipermail/public/2017-March/010194.html I don't think
this has been added to the Spring cleanup branch yet.

There's also a typo in the definition of "Authorized Port" that could be
fixed in this ballot if it goes out before the cleanup ballot: "...443
(http/s/)..."

- Wayne

On Fri, Jul 26, 2019 at 9:53 AM Doug Beattie via Validation <
validation at cabforum.org> wrote:

> I’ve updated this initial draft (attached) to address the 2 points below
> (return codes and number of redirects).
>
>
>
> Are there any other comments, or should I proceed with writing this up in
> the form of a ballot?  Are there any endorsers?
>
>
>
> Doug
>
>
>
> *From:* Doug Beattie
> *Sent:* Friday, July 19, 2019 10:32 AM
> *To:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Validation WG
> List <validation at cabforum.org>
> *Cc:* Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> *Subject:* RE: [cabf_validation] Proposed replacement for Method 6
>
>
>
> Ryan,
>
>
>
> I have no concerns from a CA point of view and just took what was in the
> Validation Summit google doc and used that.  I might have been the one that
> entered that value because we currently support just one, but I have no
> issues with the method specifying more.
>
>
>
> Are there any other items I should address before sending out an update
> and asking for endorsers?  The Validation Summit document had a few other
> items, and perhaps the most important is to determine if there are any
> security issues we want to address for those hosting companies that use
> shared IP addresses.
>
>
>
> We didn’t ever get into details about the use of query strings on the
> security or on Cache-Control.
>
>
>
>
>
>
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Friday, July 19, 2019 9:47 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Cc:* Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> *Subject:* Re: [cabf_validation] Proposed replacement for Method 6
>
>
>
> Doug,
>
>
>
> I'm not sure that there's a security reason to bound the number of
> redirects - just a question of how much processing is desired. The same is
> true, for example, when retrieving DNS records (which may go through
> multiple layers of CNAMEs).
>
>
>
> Was there a specific concern you had? I wasn't sure if it was the
> processing overhead for CAs, which they can always reduce via their CP/CPS
> (although preferably, we'd look at minimum # of supported redirects to
> provide Applicants consistency across CAs), or if there was a security
> concern you had with respect to redirects.
>
>
>
> On Fri, Jul 19, 2019 at 6:18 AM Doug Beattie via Validation <
> validation at cabforum.org> wrote:
>
> Hi Jacob,
>
>
>
> There had been a long discussion about this ballot method and I just
> pulled the notes from that into this ballot for HTTP response codes
> (clearly got that wrong) and number of redirects, so this could certainly
> be changed.
>
>    - If I’ll update it to say in the end you need a 2xx return code
>    - 10 redirects seems like a lot.  Can you tell how many redirects
>    customers are actually using, because 10 seems like a lot.
>
>
>
> Other than these 2 items, did you have some other suggestions for the
> ballot?  I wasn’t clear what you were getting at in your last paragraph and
> reference to ACME methods.
>
>
>
> Thanks!
>
>
>
> Doug
>
>
>
> *From:* Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> *Sent:* Thursday, July 18, 2019 3:57 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Proposed replacement for Method 6
>
>
>
> Hi Doug! Thanks for introducing this proposal. I'm definitely interested
> in narrowing the validation methods and specifying them more clearly.
>
>
>
> On Thu, Jul 18, 2019 at 10:30 AM Doug Beattie via Validation <
> validation at cabforum.org> wrote:
>
> *3.2.2.4.tbd Agreed-Upon Change to Website*
>
> Confirming the Applicant's control over the FQDN by verifying:
>
>    1. that the Request Token or Random Value is contained in the content
>    of a file, and
>    2. the entire Request Token or Random Value MUST NOT appear in the
>    request used to retrieve the file, and
>    3. the CA must receive a successful HTTP response (meaning that no 2xx
>    or 3xx response codes must be accepted).
>
> Is 2xx a typo here? The whole 2xx range is considered "successful." And
> forbidding 3xx is a little confusing given the accomodation for redirects.
> I think the intent here is that if there are 3xx redirects, the redirects
> cannot themselves serve as proof - there eventually has to be a 2xx at the
> end of the redirect chain. Is that right?
>
>
>
> The CA may follow only server-side redirects given:
>
>    - A maximum of 1 redirect may be followed, and
>
> Current Let's Encrypt validation policy is to follow up to 10 redirects
> <https://letsencrypt.org/docs/challenge-types/#http-01-challenge>.
> Limiting this to just 1 redirect would break some of our customers, so we'd
> be against it without a good security argument. What's the security
> justification for the limit of 1?
>
>
>
>
>    -
>    - Redirect must be only to http or https, and
>    - May be to a different Authorized Port
>
> These seem like good additions.
>
>
>
> By the way, this is reminding me that we always intended to give the ACME
> validation methods their own entries in this section once they were
> finalized, since the ACME methods are more fully-specified than the current
> methods. ACME is now RFC 8555 <https://tools.ietf.org/html/rfc8555>. What
> do you think of wrapping up that addition into this ballot? I'm happy to
> help draft.
>
> Thanks,
>
> Jacob
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190726/c4a7d65d/attachment.html>