[cabfpub] Pre-Ballot 169: Revised Validation Requirements

Richard Barnes rbarnes at mozilla.com
Tue May 3 22:02:56 UTC 2016

Hey Ryan,

I'm confused about where you're going here.

It seems like the property that we need to remedy the flaw that Peter
exposed is that the server's response cannot be generated based on the
request from the CA.  It seems to me that the right response is just to
make that requirement explicitly.  As I think JC's text does, though
perhaps it could be made clearer.

Do you agree with that approach, and we're just arguing about wording?  Or
do you think the HTTP validation method needs to be even more prescriptive?


On Tue, May 3, 2016 at 12:17 PM, Ryan Sleevi <sleevi at google.com> wrote:

> J.C.,
> Could this change?
> This provides a good example of a practice that, in the abstract, may be
> too dangerous too allow, even if it is presently practiced under Item 7 of
> the BRs. We are forced to chose between the Devil we Know (the security
> risks pointed out) and the Devil we Don't Know (all the terrible things
> that can occur under the existing Item 7/Any equivalent method)
> One option is to revise the proposed ballot to be explicit in its use of
> the presumed safe construct, rather than attempting to formalize it in the
> general. Another would be if the CA or CAs who depend on the unsafe (in the
> general) construct could change to a solution that is more objectively
> safe, when phrased in the BRs.
> I'm just trying to explore what possible solutions we may have, if any, to
> remedy this security flaw, which needs to happen either now or, if it is
> punted, immediately following the approval of this ballot.
> On May 3, 2016 8:53 AM, "J.C. Jones" <jjones at mozilla.com> wrote:
>> Tim,
>> This is deliberate. For example: ACME's HTTP validation mechanism [1]
>> includes the Random Value in the path, and the ACME server expects to
>> find in the body the concatenated string  `$random_value ||
>> $account_key_thumbprint`. The "Account Key" used in this validation is
>> not included in the request by the CA, and would only be known to the
>> CA and the Subscriber.
>> When the Required Website Content includes information not included in
>> the HTTP validation request, the highlighted risk of false-positives
>> from certain webserver configurations is mitigated. Supporting this,
>> some months back an older draft ACME was formally analyzed [2] and
>> there were no false-positive issues identified, though I haven't yet
>> seen the final report.
>> 1) https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-7.2
>> 2) https://www.ietf.org/mail-archive/web/acme/current/msg00996.html
>> Cheers,
>> J.C.
>> On Tue, May 3, 2016 at 7:47 AM, Tim Hollebeek <THollebeek at trustwave.com>
>> wrote:
>> > I'm slightly concerned that this exact text allows the "Random Value"
>> or "Request Token" to be in the path, as long as the entire RWC is not in
>> the path.
>> >
>> > Should it perhaps instead say that the Random Value or Request Token
>> part of the RWC must not appear in the path?
>> >
>> > -Tim
>> >
>> > -----Original Message-----
>> > From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of J.C. Jones
>> > Sent: Monday, May 02, 2016 2:28 PM
>> > To: Gervase Markham
>> > Cc: public at cabforum.org
>> > Subject: Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements
>> >
>> > All,
>> >
>> > One concern with mandating a prefix is that it would break the HTTP
>> validation for the ACME protocol. After some discussions, I'd like to
>> propose adding a new term "Required Website Content" and use that term in
>> the method. Credit to Andrew Ayer for the proposed text (thanks!).
>> >
>> > The diff against Ballot-169 is available at GitHub [1], and can be made
>> into a pull request (into Ballot-169 branch) if desired.
>> >
>> > New Term:
>> >
>> >   **Required Website Content**: Either a Random Value or a Request
>> Token, optionally concatenated with additional information as specified by
>> the CA.
>> >
>> > Method Change (additions in +{ }+ brackets):
>> >
>> >   ##### Agreed-Upon Change to Website
>> >   Confirming the Applicant's control over the requested FQDN by
>> confirming 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) 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 can be validated over an Authorized Port. +{The entire Required
>> Website Content MUST NOT appear in the path used to retrieve the file or
>> web page.}+
>> >
>> > 1)
>> http://scanmail.trustwave.com/?c=4062&d=15yn16AuR_LXsSVpRkrsubRsDevOE_8__pvrBZZ2xg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fcompare%2fBallot-169%2e%2e%2ejcjones%3aBallot-169%3fexpand%3d1
>> >
>> > Cheers,
>> > J.C.
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160503/58898302/attachment-0003.html>

More information about the Public mailing list