Re: [TLS] padding bug

[Nikos Mavrogiannopoulos <[e-mail]>]

On 09/24/2013 01:40 PM, Ben Laurie wrote:

>>> Can you provide a reference for your claim?
>> I believe we make circles. I previously referenced IPSec (RFC2104) at:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
>> The same RFC references the Preneel-van-Oorschot paper.
>>
>> I take your question that you actually read RFC2104 and the
>> Preneel-van-Oorschot paper and you disagree with their points?
> 
> Actually, I did, and I don't disagree with their points, but I
> disagree with _your_ points.

I am confused now. My point was to truncate the MAC and this is what
RFC2104 and the paper argues for. What do you actually disagree with?

>> PS. I attach the comment of Bart Preneel on the topic (a cryptographer
>> with significant expertise on hash functions).
> In which he says he was right for the wrong reasons. So, you need to
> reference the right papers (i.e. the ones that describe key recovery
> attacks) so we can evaluate the severity of these attacks. I am not
> aware of any even vaguely practical attacks against even HMAC-MD5, let
> alone any HMAC we're actually contemplating.
> Please present your evidence.

Since you are the one claiming that MAC truncation isn't necessary when
all existing protocols do it (even TLS does it on the Finished message
MAC), it may be better for you to present evidence that this isn't
necessary. Just add a paragraph in the Security considerations of the
existing draft. That would be sufficient for me.

> (Incidentally, he also agrees that the right answer is to have larger
> internal state, not to truncate. SHA-3 gives us this, right?).

I agree, but the discussion was about converting the old ciphersuites
that use HMAC-MD5 and HMAC-SHA1. There is no HMAC-SHA3 (in TLS or
anywhere else).

regards,
Nikos