Subject: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs?

From: Peter Gutmann <[email-masked]>
Date: Thu, 03 Nov 2011 17:38:59 +1300

TLS 1.2 allows you to specify the sig.algorithm used for various things,
alongside the bizarre choice of MD5 (why is that even in there?) there's an
option to use SHA1 alongside the TLS 1.2 default SHA2-256.  Are there any
implementations of TLS 1.2 that don't do SHA2-256?  Since the whole point of
TLS 1.2 was to move away from SHA1, I'm considering disabling it in the
possible SignatureAndHashAlgorithm options, but due to the practical
nonexistence of TLS 1.2 in the real world it's a bit hard to determine what
the consequences will be.  Would any existing implementations break if I
removed all mention of SHA1 from SignatureAndHashAlgorithm, and refused to
accept it for things like keyex sigs?  What are other implementations doing?

Peter.

---

From: Robert Cragie <[email-masked]>
Date: Thu, 3 Nov 2011 05:25:16 +0000

One real world implementation of TLS 1.2 is in the ZigBee SEP 2.0 and
ZigBee IP environment and we don't use SHA-1.

Note the swathe of cipher suites in Appendix A.5 and the mandatory cipher
suite use SHA-1. Is the proposal to clean that list up?

Robert

On Thu, Nov 3, 2011 at 4:38 AM, Peter Gutmann <[email-masked]>wrote:

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Nov 2011 08:26:44 +0200

When writing my TLS 1.2 code I tested with all the clients I could find
(IE8 with certain checkboxes checked, Opera, and OpenSSL) and none of them
would break.

On 11/3/11 6:38 AM, "Peter Gutmann" <[email-masked]> wrote:

>Scanned by Check Point Total Security Gateway.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 03 Nov 2011 21:03:49 +1300

Thanks to everyone who replied (on and off-list), in summary it looks like
it's safe to run with SHA2-256 only (or at least no SHA-1) in TLS 1.2 mode.
This also seems like the most consistent behaviour, since potential use of
SHA-1 in the PRF (where it's used as HMAC-SHA1) is safe against any known
attack while SHA-1 for sigs is potentially at risk, so using SHA2-256 for the
PRF but SHA-1 for sigs seems like a bad idea.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Nov 2011 14:55:12 +0100 (MET)

> PRF but SHA-1 for sigs seems like a bad idea.

It is actually a exceptionally stupid idea (by the TLSv1.2 spec) to use
SHA-1 only(!!) in RSA signatures.  Prior protocol versions have been
using a stronger RSA signature based on a combination of
SHA1 and MD5, so with the guaranteed availability of SHA-256,
TLSv1.2 should have done away with SHA-1 entirely.
FIPS 186-3 defines how to truncate SHA-256 for use with
DSA and ECDSA in case that the key parameter(s) were made to
match a 160-bit hash.

This change would also have simplified the question about which
hash to use for the handshake message hash in a TLSv1.2 handshake.
It seems like a stupid waste to require a SHA-256 handshake message
hash for the PRF and simultaneously a SHA-1 handshake message
hash for the KeyExchange and CertificateVerify handshake messages.

-Martin