[cabfpub] Pre-Ballot 169: Revised Validation Requirements

[Ryan Sleevi]

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):
> >
> >   ##### 3.2.2.4.6 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160503/35b0fb49/attachment.html