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

[Ryan Sleevi]

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/8be5bef1/attachment-0003.html>