[cabf_validation] Proposed replacement for Method 6

Fri Jul 26 15:59:19 MST 2019

On Fri, Jul 26, 2019 at 6:43 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> 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.
>

I sent an e-mail to the list earlier today. It's already included.

Specifically,
https://github.com/cabforum/documents/commit/6409365a19bd7e56585d20c114637226998537c8
 and
https://github.com/sleevi/cabforum-docs/commit/441094a44591384e79cf01206934a65aa7c70df0

>
> 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/)..."
>

This is also already included :) Specifically
https://github.com/cabforum/documents/commit/368da66c2396274a200c0fd408a764ce085d29de

>
> - 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/e704c286/attachment-0001.html>