Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jan 2014 19:37:18 +0100 (CET)

Manuel Pégourié-Gonnard wrote:
>
> Watson Ladd wrote:
>>
>> Even if SHA-1 is utterly broken, this won't necessarily break HMAC
>> based on it.

More importantly, with the current TLS protocol, the MAC is encrypted,
so even if SHA-1 was "broken" and HMAC-SHA1 was broken too, the
MAC would still be encrypted and therefore still be more secure than
AES-GCM ciphersuites.  (The GHASH function that is used by AES-GCM
does not have cryptographic properties to begin with).

>> 
>> I also don't like the idea of backporting: if we are going to be
>> patching systems and forcing
>> upgrades, why not to TLS 1.2 which doesn't have these issues?
> 
> Well, that was more or less my question: is using SHA-2 for HMAC with
> TLS < 1.2 really backporting? I just checked RFC 2246 and 4346 and they
> both state:
> 
>     Additional hash algorithms can be defined by cipher suites and
>     used to protect record data, but MD5 and SHA-1 are hard coded into
>     the description of the handshaking for this version of the protocol.

In spite of this wording in the document, changing the PRF in TLSv1.0
and TLSv1.1 to use a different hash is no more difficult that doing
so in TLSv1.2, this has been in active use for several years,
e.g. http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04

and it is so simple and straightforward, that it can even be done
in Microsoft Windows XP's SChannel through third-party plugins,
a TLS implementation that is TLSv1.0-only, doesn't support
TLS extensions and not even AES-CBC cipher suites (rfc3268, jun 2002).

> 
> So, I'm really under the impression that there is nothing that prevents
> anyone from defining a SHA-2 ciphersuite and using it with TLS < 1.2,
> with the understanding that the PRF (hence the handshake authentication)
> remains based on MD5 + SHA1.

It would amount ot a complete waste of resources to use HMAC-SHA256
in current TLS cipher suites,  HMAC-SHA1 is perfectly sufficient,
at least when it is encrypted like it currently is.

> 
> However, a number of facts (akr's recent message, the restriction in RFC
> 5932, the fact that neither OpenSSL nor GnuTLS accepts to negotiate any
> SHA-2 suite with TLS < 1.2) seems to indicate otherwise, so I wanted to
> check if I missed some good reason not to use SHA-2 suites with TLS <
> 1.2.

I was also surprised to see implementations fail interop for the
_SHA256 ciphersuites from rfc5246 for TLSv1.1 and TLSv1.0 with no
apparent reason.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 13 Jan 2014 20:05:03 +0100 (CET)

><[email-masked]> wrote:
>>
>> On 30/12/2013 19:44, Alyssa Rowan wrote:
>>>   - TLS 1.1/1.0: ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls }
>>>     · Not loving having to use HMAC_SHA1 but TLS 1.0/1 is stuck with it
>>
>> Are we really stuck with SHA1 (as opposed to SHA-256 or SHA-384)
>> for HMAC on TLS 1.0 and 1.1?

Encrypted HMAC-SHA1 is stronger than the integrity protection provided
by AES-GCM.  And certainly much stronger than SHA1 used in digital
signatures.

Eric Rescorla wrote:
> 
> With that said, my impression is that the use of SHA-1 in HMAC is
> comparatively strong ...
> 
> With that in mind, how much extra security benefit do we get from replacing
> HMAC-SHA1 with HMAC-<something>, as long as we still have SHA-1 for
> certificates and signatures? And if we're considering only replacing
> the MAC, it seems like it might make sense to go with a MAC that is not
> hash based at all.

NIST SP800-57 part1 says:

equivalent symmetric strength for use of SHA1 in digital signatures
is 80-bit, to-be-retired by the end of 2010 (we know how that went).

equivalent symmetric strength for use of HMAC-SHA1 as MAC is 128-bit,
good for use beyond 2030.  And this applies to HMAC-SHA1 travelling
in the clear, not the much stronger encrypted HMAC-SHA1 that TLS
is currently using for GenericBlockCipher and GenericStreamCipher.

The MAC that is used with AES-GCM (AES-encrypted GHASH) is substantially
weaker than AES-encrypted HMAC-SHA1.  For the specific case of TLS,
this should not normally be a problem, however.  For TLS-protected
traffic, we desire the confidentiality to last for several years to
come, even if someone captures and archives TLS-protected communication
today in order to attack it at some point in the future.

For the MAC that protects TLS traffic, we do not need as much of a
security margin as for the encryption, because a successful attack
only creates a problem when it happens in near real time, i.e. while
the communication channel that uses the respective traffic protection
keys is still established.  After the TLS connection terminates,
there are no more benefits from obtaining the MAC keys that were
used on that connection.

The average TLS connection is fairly short-lived (seconds, minutes,
sometimes a few hours).  But there may be consumers of TLS that keep
a connection open for a much longer time, or use it to transfer
huge amounts of data (xx gigabytes or more), and for those, the
actualy safety margin of the MAC may become relevant, and whether
that safety margin of the MAC goes down with the amount of data that is
transfered -- IIRC the latter applies to AES-GCM.

-Martin