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

[Ryan Sleevi]

On Jun 2, 2014 6:12 AM, "Rob Stradling" <rob.stradling at comodo.com> wrote:
>
> On 02/06/14 10:40, Ryan Sleevi wrote:
>>
>> On Jun 2, 2014 2:13 AM, Rob Stradling wrote:
>
> <snip>
>>
>> > Ryan, why is "hash of their CSR" insufficient, in your opinion?
>>
>> 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.
>
>
> I agree that "hash of their CSR" alone is insufficient.
>
> The "hash of their CSR" methods that we currently use at Comodo also
require the applicant to state the domain name of the authorized CA (à la
CAA).
>
> As for "unique per...request" - well, the CSR _is_ the request (from my
point-of-view as a CA techie at least!)
>
>
>> 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.
>
>
> The attacker would need to know the hash they're trying to create a
collision for.  Why would anyone besides the CA and the applicant ever see
the CSR or its hash?
>
> TBH, I think it's useful to incorporate verification of the CSR's
authenticity into the "demonstration of control" process.  Otherwise, isn't
there a risk that an attacker might somehow (perhaps via social
engineering, or by MITM'ing an insecure CSR upload form) interfere with a
legitimate certificate application, substituting the real CSR for a fake
one?
> (If attack successful, then the CA uses the fake CSR to issue Cert A;
then the legitimate customer complains that Cert A "doesn't work"; then the
CA shrugs it shoulders and does a reissue - Cert B, which the legitimate
customer is happy with; the CA doesn't revoke Cert A because the attack
went undetected; meanwhile, the attacker downloads the unrevoked Cert A,
for which they have the associated private key, from one of the CT Logs...)
>
> I think adding baseline requirements for permitted (combinations of) hash
algorithms for "hash of their CSR" methods might be a good idea though.
>

In practice, we tend to see filesystem-based verifications result in files
being left on the root system, perhaps indefinitely. Additionally,
enumerating file names - even without their contents - is also a fairly
common attack.

So the disclosure of the hash of the CSR is arguably not secret, and it
provides a stable identifier for an attacker to attempt a collision with.
The PKCS#10 format provides ample attack for using extensions to induce a
collision, and most CAs simply ignore unrecognized CSR extensions, rather
than reject.

One attack would be to induce a collision on a CSR with an alternate SPKI
using a dummy extension.

Another attack would be using the same CSR, but provided to another CA, CA
B. The attacker does not hold the private key (yet), but obtains an
additional certificate. Then, using a technique like Heartbleed, obtains
the private key at some later point.

The legitimate customer revokes their certificate with their known CA, CA
A. Assuming revocation worked reliably (eg: must-staple), that certificate
and key pair would now be invalid. However, the attacker holds a
still-valid certificate, from CA B, and now holds the private key as well.
Without compromise of any CA, and without awareness of the subscriber (sans
CT), they can now mount a MITM.

Our goal with this proposal is to reduce or eliminate as many places as
possible where MITM can be achieved without compromise of the CA and
without detection (or tools for mitigation) on the subscriber's behalf.
This is part of the motivation for strong CAA, CT, and now this proposal,
as they are all attempts to close holes we view in the issuing process
where both CA and subscriber can be adhering to BRs and best practices, and
still have secure communication with users compromised.

The incorporation of the CA name into the file may mitigate part of these
attacks, but not all. That said, it is no doubt something to consider -
although something we can't rely on being universal today, so we would
certainly want to enshrine it in the BRs if that is the route we go.

>
>> 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.
>
>
> IANAL, but IIRC, demonstration of control using a CA-generated random
number is encumbered, whereas "hash of their CSR" is (hopefully) not.
>

Well, this is just a prickly pear. I, too, am not a lawyer, but do feel
like we should be striving for the best security possible. Without having a
reference to these possible encumbrances, we are no more likely to, as a
forum, design around them. As such, I would much prefer we continue down
the path of random numbers until such a time as the Forum becomes aware of
the details of the possibly encumbered techniques. Then, presumably with
the advice of our respective counsel, we can decide to proceed or design
around.

If we find ourselves recommending a particular technique, and then later
find it encumbered, then we are at the same risk as with every other
requirement of the BRs, and can update accordingly. Luckily, multiple
alternatives exist for the validation of domains, so encumbrance would not
halt CA's issuances.

>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/82e3afdf/attachment-0003.html>