Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla <[e-mail]> 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 .....


> Because the attack model for MACs is not the same as the attack model
> for encryption. The encryption is susceptible to offline attack, whereas
> with a MAC all you need to do is get the guessing probability sufficiently
> low because *any* failed forgery causes connection termination.

This depends on the threat model you have. There might be cases where
the case you describe is no problem for the adversary.

regards,
Nikos