Re: [TLS] TLS 1.2

Eric Rescorla <ekr@rtfm.com> writes:

>I'd like to start a discussion on whether we should be thinking about a TLS
>1.2 that was more oriented towards newer hash functions. Obviously, we're not
>at a point where there's a crisis yet but it doesn't hurt to be prepared.

I've actually had a proposal for fixing TLS' broken signatures sketched out
probably since it was still SSL, so perhaps we can use this to fix several
problems at once.  Firstly, in terms of attacks on hash functions, the only
thing that really needs to be addressed is the use of hash functions as, well,
hash functions.  Most of the use in TLS is as PRFs and in HMAC, none of which
are even remotely endangered by any known attack.  Signatures, however, need
to be fixed for three main reasons:

1. Use of potentially at-risk hash functions, as already noted.

2. Use of a )*#&%*$( nonstandard signature format that a number of crypto
   devices (and libraries) either don't support at all, or have broken support
   for.  Trying to determine by trial and error which (say) smart cards
   support the weird SSL signature mechanism alongside the default PKCS #1
   one, and then detecting which firmware revisions have which bugs in
   handling the format (claim to support it but don't, support it but add an
   ASN.1 wrapper at the start, only use one of the two hashes, and some other
   oddities that I've forgotten) is an absolute nightmare.

3. Signing of hashes that don't correspond to anything that's calculated
   during part of the normal handshake.  That is, the dual-MAC that's sent in
   the Finished message isn't what gets signed, so it's necessary to run a
   parallel hash of handshake messages that terminates before the Finished-
   message hashing does.  Since client certs are almost never used, there's a
   lot of extra overhead involved in running an extra dual hash that (most of
   the time) never gets used.  In practice all that's needed is to sign the
   client and server nonces to ensure signature freshness,

So my proposal was to include a new extension signatureSuites, consisting of
(currently) three values:

  SIG_RSA_PKCS1_WITH_SHA1
  SIG_RSA_PKCS1_WITH_SHA256
  SIG_DSA_WITH_SHA1

and if that gets acknowledged by the other side (as per RFC 3546) then using a
standard signature of the given type over the value:

  { "certificate verify" || client_nonce || server_nonce }

So if the signature suite chosen was SIG_RSA_PKCS1_WITH_SHA1 then the cert-
verify would contain a completely standard PKCS #1 signature over the above
data.

(Once this was added to the standard, I'd take the old signature mechanism and
 stomp on it and dance around it and sing hallelujah on its grave).

Peter.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls