[Ach] Algorithm Check on Path Validation?

[Rainer Hoerbe]

>> So the better crypto config should at least warn deployers about products that do not protect against weak signatures. 
> 
> 
> The conclusion here is that Better Crypto can therefore help the PKI
> mess.  I'm not sure, but we've been around this several times, and
> serves little restate the arguments about scratching the surface and
> looking like you've made a difference.
> 
> One way to solve this would be to have a general specification of what
> algorithms are acceptable.
Teaching people the difference between a hash in an HMAC and in a digest? Having them drawing informed decisions from the general spec when doing a configuration? IMO that is asking too much. To achieve an impact you need recipes and put the background into the annex, just like the ACH document is structured now.

> 
> E.g., list RSA<1536 and MD5 as bad, SHA1 as deprecated.  The problem
> with this is that we'll run into trouble with SSL which has RC4, 3DES
> and MD5 in abundance...
> 
> Another way to deal with this is to point out that the smaller key sizes
> may be at risk of an attack, and if the private CA protects a high value
> target, they need to fix it.  That's a more business-oriented approach,
> but it won't satisfy the numerologists.

I should have clarified the use case I am concerned about. Client certificate validation can be used to authenticate security gateways or fat clients. Broken path validation can lead to impersonation and compromise. This is not the 99% SSL use case, but an essential security feature for the rest. A similar case would apply to client hardening. If I interpreted the docs correctly: specifying a hardened NSS cipher suite for Firefox does not apply to path validation, only the hard-coded default of RSA>= 1024 and !MD5 . Another case are the SSL-protected SW update feeds and signed software components. Yes, the latter ones are out of scope for the time being, but the first one should not.

Therefore it is not good enough recommending key sizes, when deployers are left alone about the way a cipher suite is applied. For example, when one takes the ACH recommendation ...:!MD5:... in the mod_ssl config, there is a high chance to miss the point that SSLCipherSuite does not apply to path validation of client certificates. Reads the docs does not really help, either.

My proposal is to following text to "2.1 Web Servers":
===
While certificate validation is out of control for the most common scenario, where an unmanaged client is accessing the web server, there are cases when certificate validation is crucial. Common cases are web service clients, fat clients and security gateways. For this cases following caveat needs to be considered:
The proposed cipher suites do not apply to all relevant cryptographic operations pertaining to SSL security, in particular they do not check algorithms encountered in end-entity and intermediate certificates. An adversary might inject a fake certificate into the chain using a weak algorithm. Possible work arounds are:
* Switch to a product that provides some documented minimum strength (e.g. IIS, NSS reject signatures with RSA < 1024 or MD5).
* Add custom code in a server plugin or at the application level. E.g. have the webserver export the cert chain into the request and do some additional path validation yourself
* File a security vulnerability with your vendor/OSS project and ask for a configurations option to require algorithms and keylengths for certificates keys and signatures. You might have to call it a feature request.
===

I could not perform practical research on this, except the observation that client certificates using RSA1024/MD5 seem to be happily accepted by a number of web servers. So any validation of my assumptions is very welcome.

- Rainer