Re: [TLS] Time for ciphersuites with new hashes?

[Jack Lloyd <lloyd@xxxxxxxxxxxxx>]

Personally, I'm more concerned with the fact that the authorization process is
fixed with SHA-1 (or MD5+SHA-1 for RSA) with no upgrade path. I still feel
pretty comfortable with HMAC/SHA-1 for now, though a new set of AES+SHA2
ciphersuites would be easy to specify and probably couldn't hurt.

Any thoughts on adding a TLS extension for negotiating different hashes for
authorization? DSA might be a little tricky, since AFAIK NIST still hasn't
approved larger keys, and you would lose quite a bit of hash space by using
SHA-2 with a 160 bit q. But RSA could be trivially ugpraded to use SHA-512 with
normal PKCS1 v1.5 padding instead of the MD5/SHA1 with the PKCS-variant padding
that's currently used. It would be difficult to mount a succesful attack
against the handshake in realtime, given the current workload of even just an
MD5 collision, much less 2^69 operations for SHA, but by the time such an
extension is actually widely implemented, I suspect those will have been
reduced quite a bit.

Basic outline:

Client extension:

enum {
   sha256(0), sha384(1), sha512(2), (255)
} SignatureHash;

struct {
   SignatureHash hash_list<1..2^8-1>; /* sorted by client preference */
} SignatureHashList;

Server extension:

struct {
   SignatureHash hash; /* whichever one the server prefers */
} SignatureHashResponse;

If negotiated, the RSA signatures uses standard PKCS #1 padding with the chosen
hash, DSA continues to use raw unpadded hashes as normal.

Flame away,
  Jack

On Wed, Feb 16, 2005 at 02:44:14PM -0800, Nelson B Bolyard wrote:
> In light of the news that SHA1 has been "broken"
> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
> (collisions can be found with much less work than predicted),
> is it time for us to be defining new ciphersuites that employ
> SHA256, SHA384 and/or SHA512?
> 
> /Nelson
> 
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls

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