Re: [TLS] draft-turner-ssl-must-not

[Marsh Ray <[e-mail]>]

On Sun, Jul 04, 2010 at 01:31:44PM +0200, Bodo Moeller wrote:
>
> MD5 and SHA-1, of course, *do* use a small state, but let's be 
> clear what the scope of the theoretical result actually is.

Well, I thought it was pretty cool. :-)

Last I heard SHA-1 was down to 2^69 and MD5 2^24.
http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf
http://www.win.tue.nl/hashclash/On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf

> Also, don't forget that the use of these hash functions in TLS 1.0  
> doesn't actually have the ambitious goal of collision resistance

It would be really great if this kind of thing had been documented as
part of the design process. The Glossary section of RFC 4346 talks
about collision resistance as a property of MD5 and SHA-1.

Recently there have been some proposals for extensions to TLS which
loosen up some ordering dependencies or even change the crypto quite
dramatically. It would be unfortunate if some under-documented
assumptions were accidentally violated because they weren't well
understood.

> -- it's 
> just that it uses ingredients that were meant to deliver this (but
> which,  even if failing at this, don't completely break apart: 
> http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html).

Again, RFC 4346:
------------------
   When this message will be sent:

      This message is used to provide explicit verification of a client
      certificate. 
	.....
      struct {
           Signature signature;
      } CertificateVerify;

      struct {
          select (SignatureAlgorithm) {
              case anonymous: struct { };
              case rsa:
                  digitally-signed struct {
                      opaque md5_hash[16];  <----- Note concatenated
                      opaque sha_hash[20];  <----- non-HMAC hashes here.
                  };
              case dsa: ...
              };
          };
      } Signature;

      CertificateVerify.signature.md5_hash
          MD5(handshake_messages);

      CertificateVerify.signature.sha_hash
          SHA(handshake_messages);

   Here handshake_messages refers to all handshake messages sent or
   received starting at client hello up to but not including this
   message, ....
------------------

So we definitely have some red flags going up here:
   * Raw hashes used without HMAC for signing important stuff
   * Concatenated iterated hash functions
   * Mitm can manipulate variable-length data under the hash in both
     directions

These suggest the possibility of a client cert credential stealing attack
(for the purely theoretical attcker who can collide SHA-1s within the
handshake timeout).  There are any number of reasons this might not
translate into a practical attack, but I think it supports a couple of
points:

   * Some aspects of TLS security have excessively subtle dependencies.

   * The Joux attack on concatenated iterated hashes is relevant to TLS.

   * TLS 1.0 and 1.1 are quite possibly pwned with the first published
     collision of SHA-1 and should be deprecated along with other uses
     of SHA-1.

   * Client certificates are not the solution to everything ;-)
 
- Marsh