[cabfpub] For discussion: Restricting the use of file-based demonstrations of control

[Rich Smith]

Ryan said:

"...we would at least like to be able to provide reliable guidance and 
security practices for the many hosting services that do allow modifications 
of the root."



If that's the goal, shouldn't the first sentence of such guidance be, "Hey 
numbskull, secure your root"?



Not saying we shouldn't tighten up the language in the BRs some, but I also 
don't think we should go so far as to define the exact procedure every CA MUST 
follow and thereby prevent future innovation and improvement.



-Rich





From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, June 02, 2014 9:23 AM
To: Rich Smith
Cc: Rob Stradling; CABFPub
Subject: RE: [cabfpub] For discussion: Restricting the use of file-based 
demonstrations of control




On Jun 2, 2014 6:01 AM, "Rich Smith" <richard.smith at comodo.com> wrote:
>
> Ryan,
>
> We can certainly make changes should the Forum decide that's the best 
> course, however, our HTTP based DCV is as follows:
>
>
>
> HTTP-based DCV
>
> The CSR you submit to Comodo will be hashed. The hash values are provided to 
> you and you must create a simple plain-text file and place this in the root 
> of your webserver and served over HTTP-only!
>
> The file and it's content should be as follows:
> http://yourdomain.com/<Upper case MD5 hash of CSR>.txt
>
> Content (as a plain text file):
>
> <SHA1 hash of CSR>
> comodoca.com
>
>
>
> I don't see how having some specific sub-directory helps if the site 
> operator is not already preventing end users/others from modifying their 
> root directory, and as you can see, we already have a requirement for a 
> reference to the CA to be in the contents of the text file.  I can sort of 
> see your point with respect to hash collisions, but I don't really think 
> that it's that relevant if you are requiring the hash in a specific place 
> that SHOULD be under the sole control of the site operator.  If the site 
> operator is allowing all and sundry to write to the root directory of their 
> site that's monumentally stupid, and I don't see any change we can make here 
> fixing stupid.  If the site owner is already allowing writes to the root 
> directory, what makes you think they will better secure some sub-directory? 
> In my experience when you think you've made something idiot proof, what you 
> have actually done is create conditions for someone to come up with an 
> improved model of idiot.
>

While you may view it as monumentally stupid, the reality is that a vast 
number of services already permit this. It is common enough that we here no 
longer view it as an affective demonstration of control. Given that CAs are 
often focused on security through the lens of cryptography and identity, 
rather than on web application security, and may thus be unaware of how common 
it is, this is why we are bringing the issue to the Forum to begin with.

While file based verifications are a poor substitute for *domain* validation, 
for all the reasons that have been enumerated as problematic with CAA (most 
notably, the case of site operator != domain operator), we would at least like 
to be able to provide reliable guidance and security practices for the many 
hosting services that do allow modifications of the root.

Further, even though Comodo may be using this particular scheme, the way the 
BRs are written permit any number of creative interpretions - including files 
in subdirectories, as discussed on the call - so we really are in a similar 
position to how email validation behaved a decade ago.

>
>
> If the Forum decides we need to change, we'll change, but with the possible 
> exception of the hash collision issue, I don't really see anything you're 
> proposing as a big security improvement on what Comodo is already doing.
>
>
>
> Regards,
>
> Rich
>
>
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On 
> Behalf Of Ryan Sleevi
> Sent: Monday, June 02, 2014 5:40 AM
> To: Rob Stradling
> Cc: CABFPub
> Subject: Re: [cabfpub] For discussion: Restricting the use of file-based 
> demonstrations of control
>
>
>
>
> On Jun 2, 2014 2:13 AM, "Rob Stradling" <rob.stradling at comodo.com> wrote:
> >
> > On 30/05/14 02:09, Ryan Sleevi wrote:
> > <snip>
> >
> >> Proposal 1: Remove 11.1.1 (6)
> >> Alternate: Provide a single, explicit path and set of steps that must be
> >> done, so that there is consistency between the CAs that employ this
> >> method. One path that might suffice would be one based upon RFC 5785.
> >>
> >> For example, /.well-known/certificate-request . Within that file, we
> >> could either establish a structure (seems complex), or simply require
> >> that the applicant place a random string that is generated by the CA
> >> (eg: it is not influenced by the applicant, such as a value of their
> >> choosing, hash of their CSR, etc).
> >
> >
> > Ryan, why is "hash of their CSR" insufficient, in your opinion?
> >
> > Thanks.
> >
> > -- 
> > Rob Stradling
> > Senior Research & Development Scientist
> > COMODO - Creating Trust Online
> >
>
> The first reason is simple - it is not unique per CA/request, thus multiple 
> CAs could rely on expecting to see the same value. As such, it is not a 
> practical demonstration that the applicant is authorized to request the 
> cert.
>
> The second is the same reason we require entropy in the serial number or 
> portions of the issued cert that are not under the applicant's/attacker's 
> control - weaknesses in the hash algorithm used may lead to collisions, as 
> we saw with Flame.
>
> Requiring a cryptographically strong random number per request/verification 
> creates a stronger verification method than a naive implementation. Given 
> how weak URL based verifications are to begin with, this is important.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/27bab48b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/27bab48b/attachment-0003.bin>