On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos
<nmav(_at_)gnutls(_dot_)org> wrote:
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla <ekr(_at_)rtfm(_dot_)com> wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have been reused
for other purposes already:
No, I'm not forgetting that. That doesn't change the fact that the
computation is
a MAC.
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.
For me the ciphersuites defined in TLS should have a uniform
security level. I.E. why use AES-256 with security level of 2^256
but use a MAC for a handshake of 2^96 bits?
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.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf