On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos
<nmav(_at_)gnutls(_dot_)org> wrote:
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla <ekr(_at_)rtfm(_dot_)com> wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?
If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.
In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.
Such things should be explicit then. In any case I think there is a mistake
here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
PRF, and the AES-128 ciphersuites with SHA-256, thus there was
intention to match the security strength of the cipher with the size
of the hash.
If this wasn't the intention, then it is pretty much misleading, and should
be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
is being truncated in 96 bits. The choice for SHA-384 was because .....
I'm not one of the authors of that draft, but I imagine for the usual
reason of tiling
the space of algorithms (not that I consider it a great reason.)
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf