<p dir="ltr"><br>
On Jun 2, 2014 6:12 AM, "Rob Stradling" <<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>> wrote:<br>
><br>
> On 02/06/14 10:40, Ryan Sleevi wrote:<br>
>><br>
>> On Jun 2, 2014 2:13 AM, Rob Stradling wrote:<br>
><br>
> <snip><br>
>><br>
>> > Ryan, why is "hash of their CSR" insufficient, in your opinion?<br>
>><br>
>> The first reason is simple - it is not unique per CA/request, thus<br>
>> multiple CAs could rely on expecting to see the same value. As such, it<br>
>> is not a practical demonstration that the applicant is authorized to<br>
>> request the cert.<br>
><br>
><br>
> I agree that "hash of their CSR" alone is insufficient.<br>
><br>
> 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).<br>
><br>
> As for "unique per...request" - well, the CSR _is_ the request (from my point-of-view as a CA techie at least!)<br>
><br>
><br>
>> The second is the same reason we require entropy in the serial number or<br>
>> portions of the issued cert that are not under the<br>
>> applicant's/attacker's control - weaknesses in the hash algorithm used<br>
>> may lead to collisions, as we saw with Flame.<br>
><br>
><br>
> 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?<br>
><br>
> 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?<br>

> (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...)<br>

><br>
> I think adding baseline requirements for permitted (combinations of) hash algorithms for "hash of their CSR" methods might be a good idea though.<br>
></p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">One attack would be to induce a collision on a CSR with an alternate SPKI using a dummy extension.</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">><br>
>> Requiring a cryptographically strong random number per<br>
>> request/verification creates a stronger verification method than a naive<br>
>> implementation. Given how weak URL based verifications are to begin<br>
>> with, this is important.<br>
><br>
><br>
> IANAL, but IIRC, demonstration of control using a CA-generated random number is encumbered, whereas "hash of their CSR" is (hopefully) not.<br>
></p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">><br>
> -- <br>
> Rob Stradling<br>
> Senior Research & Development Scientist<br>
> COMODO - Creating Trust Online<br>
><br>
</p>