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

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 16 Feb 2005 14:44:14 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Jack Lloyd <[email-masked]>
Date: Wed, 16 Feb 2005 16:28:03 -0700

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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 17 Feb 2005 16:51:12 +1300

Nelson B Bolyard <[email-masked]> writes:

>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?

Just to put this into perspective:

- It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC,
  so the core of SSH, SSL/TLS, etc etc are unaffected.

- I've seen one report that it only affects the compression function and not
  the full hash function, which sounds plausible.  SHA-1 (and indeed all of
  the MD4-type UFN hash functions) use a core compression function and then
  perform extra operations for the full hash function, so finding collisions
  in the full hash is somewhat more difficult than just the compression
  function.

- It takes 2^69 ops on average to find a second input value that produces the
  same output as the first one (the ambiguous phrasing here is meant to
  indicate that probably the compression function produces the same output
  rather than the full SHA-1 hash producing the same output, see above).  The
  second input value can't be chosen by the attacker, so the chances of
  forging a signature on structured data like a certificate or CMS/PGP message
  are fairly remote.

So while it's a very interesting result, it's more a hint to consider moving
to something else rather than time to hit the panic button.  RIPEMD-160 still
looks fairly secure, my gut feeling is that its dual-path construction is
safer than the SHA-1 derived SHA-256 et al, but I suspect that in the light of
the current work on attacking UFN-based designs we'll be seeing a pile of new
non-UFN hash functions in the same way that differential cryptanalysis spurred
a burst of work on new ciphers.

Peter.

---

From: Jeff Williams <[email-masked]>
Date: Wed, 16 Feb 2005 23:38:36 -0800

Peter and all,

  I think your under playing this a bit.  Once you have found holes
and/or collisions in compression it is short work to determined
other collisions if the full hash...  Moving away from SHA-1
is really overdue, but not yet entirely necessary...

> a burst of work on new ciphers.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Peter Watkins <[email-masked]>
Date: Thu, 17 Feb 2005 09:03:32 -0500

On Wed, Feb 16, 2005 at 04:28:03PM -0700, Jack Lloyd wrote:
> fixed with SHA-1 (or MD5+SHA-1 for RSA) with no upgrade path.

My thoughts: I'm still much more concerned about promoting something
like "RSA ephemeral" for some sort fo forward secrecy improvements.
The weak link for 99% of real world TLS/SSL implementations is keypair
management, since so few folks are using expensive tamper-resistent
crypto hardware for their server ends, and the hash function is a moot
point if an attacker can sniff traffic in anticipation of scoring a/the
server keypair from some social/meatspace hack.

I know Sun and Microsoft don't like specs that mandate forward secrecy,
but I'd like to see this WG start to incorporate forward secrecy as a
core component of future ciphersuites, even if only "ephemeral" keypairs
that leave wiggle room for TLS server vendors.

-Peter

---

From: Jack Lloyd <[email-masked]>
Date: Thu, 17 Feb 2005 07:19:32 -0700

On Thu, Feb 17, 2005 at 09:03:32AM -0500, Peter Watkins wrote:

[...]
> that leave wiggle room for TLS server vendors.

Don't the DHE ciphersuites provide PFS already? Am I missing something?

-Jack

---

From: "Gregory S. Chudov" <[email-masked]>
Date: Thu, 17 Feb 2005 18:23:00 +0300

Greetings!

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

> authorization?

[skip]

I am currently working on a draft, proposing such an extension.
It was mentioned on the list, that a different PRF would suit better for
PSK.
Besides, SHA-1/MD5/PRF cannot be used with GOST cipher suites.
So we have plenty of reasons already to create an extension, which
would allow PRF and authorization hash negotiation.

Good luck,
Greg Chudov.

---

From: "Nelson B. Bolyard" <[email-masked]>
Date: Thu, 17 Feb 2005 09:09:31 -0800

> is really overdue, but not yet entirely necessary...

Right.  It's not yet a panic, but we can see it coming, so NOW is the
right time, IMO.

 >>to something else rather than time to hit the panic button.

Right.  Let's not delay doing this work until the panic has begun.

-- 
Nelson B

---

From: Peter Watkins <[email-masked]>
Date: Thu, 17 Feb 2005 16:58:51 -0500

> Don't the DHE ciphersuites provide PFS already? Am I missing something?

The trouble is that most traffic is protected with RSA suites, so we should
be very concerned about the protection that RSA suites offer.

RSA_EXPORT offers some forward secrecy via the temporary key mechanism, but
the "standard" RSA suite set does not. 

I had been under the impression that most servers were using the non-EXPORT
RSA ciphersuites, but now that I examine some certificates I see mostly RSA
keys with >= 1024 bit moduli -- which would necessitate server key exchange
messages negotiating RSA_EXPORT.

I also see Certificate Authorities like Verisign recommending 1024+ bit 
server keypairs, and vendors of TLS-using server software like Sun and 
Microsoft defaulting to 1024 bits or better in their keypair creation.

So the good news is that the current state of affairs is better than I feared,
and my "weak link" statement seems to be way off base.

But there's an irony: it's only because of US export law that TLS servers with
large RSA keys are using the server exchange mechanism to switch to the 
RSA_EXPORT temporary key mechanism and negotiate a suite with some forward
secrecy. 

I'd like to see future ciphersuites include forward secrecy (perfect or not) as 
a core design goal, not some accidental benefit as we have now.

-Peter

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Feb 2005 14:55:36 -0800

> be very concerned about the protection that RSA suites offer.

But that's purely a matter of how people configure their implementations.
You can do DHE with the RSA certificates that people now standardly
have.

> messages negotiating RSA_EXPORT.
I believe you're mistaken here. The vast majority of SSL connections
use static RSA, no matter what the key size in the certificates.

-Ekr

---

From: Jeff Williams <[email-masked]>
Date: Thu, 17 Feb 2005 22:56:09 -0800

Nelson and all,

  With regards to SHA-1 AND DES/3DES we are in agreement..
There is no panic yet, and if this is addressed in a expedient manner
there need not be a panic.  However, waiting very long would be
a mistake that would lead to a panic decision mode which is
almost always a disaster of one proportion or another...

Regards,