On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx> wrote:
> On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla <ekr@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf