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

[[e-mail] (Martin Rex)]

><[e-mail]> 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