[Ach] Algorithm Check on Path Validation?

[Rainer Hoerbe]

Am 25.01.2014 um 21:22 schrieb ianG <iang at iang.org>:

> On 25/01/14 21:12 PM, Rainer Hoerbe wrote:
>> A potential problem with weak CA signatures (using RSA 1024 and/or MD5) will remain for some time. According the the current cab policy RSA 1024 and MD5 have been banned only for certificates issued from 2011 onwards.
> 
> I think ordinary MD5 is already out.
I became aware of that when I encountered it with a private CA. It is obviously being accepted by usual deployments such as apache and enterprise load balancing HW. What would stop someone to fake a cert exploiting an MD5 collision just claiming that a shiny comodo cert was created with rsa1024/md5, if the client does not reject it?

>  What is allowed now is MD5+nonce.
> Which is fine into the distant future as it rules out the collision attack.
> 
> 
>> Certificates with lifetimes of 5 or 6 years (like Go Daddy Secure Certification Authority, or a-sign-SSL-03) will weaken the PKI-ecosystem until 2016 (or later, if some CP allow for that).
>> 
>> As a mitigation these CAs would have to disappear from the hardened crypto universe. What are the options?
>> 1. remove the weak ones from the trust list in advance:
>>  1.1 eliminated root CAs that use weak self-signing algorithms
> 
> 
> There's no such thing as a root CA weak self-signing algorithm.   The
> signature is on the cert only in order to turn it into a cert;  all
> security for a root CA is derived by its position on a root list, not on
> any cryptographic properties on the signature.
sure, now that I think about this.

> 
> As a practical non-security issue, eager beavers in the browser world
> are deprecating MD5 for *everything* without resort to its still good
> non-collision properties.  So they are in effect dropping it for root
> CAs as well.  Oh well.
> 
> 
>>  1.2 find out popular intermediate CAs and apply the same
>>  1.3 check CPs to find out those that create weak end entity certs
> 
> 
> (These two steps are being conducted by Browser Vendors and/or CABForum.
> Why bother?)
> 
> 
>> 2. Limit the trust store to a small number of ... CAs
> 
> Now we're talking ... So, who gets dumped?
> 
>> 3. check for algorithms during the cert path validation
> 
> (That's tech, not config.  Interesting but out of scope here.)
> 
>> Re 1. The first step (1.1) seems to be quite feasible to do, but does not really protect agains weak certificates down the chain. Intermediate CAs may be discovered dynamically, so weak intermediate CAs or those issuing weak end entity certs are hard to protect against.
>> 
>> Re 2. As already discussed on this list, this is probably more complicated than making long-lasting peace in the Middle East.
>> 
>> Re 3. I am not aware of tools that would do this. Yes, one could write some mod_ssl_extra_path_val, but that seems to be more than a lost weekend.
>> BTW, the NIST Path Validation Test Suite (PKITS) does require products to use only SHA-256 for signatures. But it is only applicable to a subset of vendors supplying the US federal government (the IBM/Oracle/Entrust/etc. world).
> 
> 
> (Everything NIST does is oriented towards the USG for crypto at least.
> It's their mandate.  They don't do industry ... why is anyone listening
> to them?  I have no idea...)
> 
> 
>> Any ideas?
> 
> 
> Relax.  Ignore NIST, ignore CABForum.  Just so we're not accused of
> racism or xenophobia, ignore all other standards bodies.  Those guys are
> high on their own cryptographic numerology.  If they were actually
> interested in security they'd be telling the browsers to sort out their
> non-security-UI.
> 
> They're not doing that.  You might note that friends of theirs are
> implicated in spear-phishing attacks against the browsers'
> non-security-UIs.  LinkedIn is repeatedly mentioned.  Nobody wants to
> stop the party, everyone's courting the sex, not watching the alcohol
> content.
> 
> Remember, nobody's crunched 1024 as yet.  When they do, it's only one
> RSA key...  MD5 was collision attacked in around 2005.  It wasn't until
> 2009 or so that Jake&friends did a collision attack on a root cert using
> raw MD5.
Agreed. I am not so concerned about rsa1024, but about MD5, unless one can be sure that this has been rooted out completely.

- Rainer
> 
> 
> 
> iang
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach