Subject: RE: [TLS] Time for ciphersuites with new hashes?

From: [email-masked]
Date: Thu, 17 Feb 2005 11:01:40 +0200

Another possibility would be to define a set of new TLS key
exchange algorithms (RSA2/DH_RSA2/DHE_RSA2/something, either
PKCSv1.5 padding with SHA-256, or maybe PKCSv2.1 PSS padding),
and new ciphersuites based on those, something like:

TLS_RSA2_WITH_AES_256_CBC_SHA256
TLS_RSA2_WITH_something_else
TLS_DH_RSA2_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA2_WITH_AES_256_CBC_SHA256  
(...)

This way, we could use the existing TLS ciphersuite negotiation
logic without needing anything new there. And since TLS already
has a large number of different key exchange algorithms (my last
count was around 20, including the most stable internet-drafts),
adding a couple more would probably fit the TLS architecture
reasonably nicely.

(But certainly adding a TLS extension would also get 
the job done.)

Best regards,
Pasi

> -----Original Message-----
> From: Jack Lloyd
> Sent: Thursday, February 17, 2005 1:28 AM
> To: [email-masked]
> Subject: Re: [TLS] Time for ciphersuites with new hashes?
> 
> 
> 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

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls