Re: [TLS] padding bug

["Paterson, Kenny" <[e-mail]>]

Hi all,

I was not going to join this debate, which seems to be essentially
political rather than technical, but I guess I should. I already (in a
previous post) pointed to the state of the art on attacks against HMAC:

http://www.ietf.org/mail-archive/web/tls/current/msg09824.html


My conclusion there was that HMAC with all current TLS hash functions is
fine without any truncation in an encrypt-then-MAC construction (wherein
the MAC output is exposed as part of the ciphertext), but we should avoid
HMAC-MD5 just to be conservative.

Now I just wanted to remind everybody that truncating MAC outputs is not
ALWAYS a good idea. Specifically, in the context of TLS's
MAC-then-PAD-then-Encrypt construction, it has been known for some time
that short MACs coupled with TLS's support for variable length padding
allows an attack. See Section 5 of this paper:

http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf


(published at Asiacrypt 2011).

This is not to say that truncating TLS MACs in an encrypt-then-MAC
construction is inherently dangerous in the same way. It's not. But I just
wanted to make sure it was properly understood that truncation can also
have negative security consequences, depending on how the MAC is used as
part of a protocol.

Cheers

Kenny



On 24/09/2013 13:48, "Blumenthal, Uri - 0558 - MITLL" <[e-mail]>
wrote:

>Guys,
>
>Isn't it enough already? Sufficient evidence, including publications by
>respected cryptographers, has been presented to adequately demonstrate
>that truncating MAC has security advantages over including the entire
>output of the hash function. That was the primary reason/justification
>for truncating MAC in IPsec.
>
>FWIW, the reasoning of that paper applies to SHA3 as well, though
>arguably that extra security measure is unnecessary there.
>
>P.S. Peter, I admire your ability to keep arguing well past the logical
>defeat. <half-smile>
>
>--
>Regards,
>Uri Blumenthal                            Voice: [phone]
>Cyber Systems and Technology   Fax:   [phone]
>MIT Lincoln Laboratory                Cell:  [phone]
>244 Wood Street                        Email: <[e-mail]>
>Lexington, MA  02420-9185
>
>Web:  http://www.ll.mit.edu/CST/
>
> 
>
>MIT LL Root CA: 
>
> <https://www.ll.mit.edu/labcertificateauthority.html>
>
>
>DSN:   478-5980 ask Lincoln ext.1638
>
>----- Original Message -----
>From: Peter Gutmann [mailto:[e-mail]]
>Sent: Tuesday, September 24, 2013 08:31 AM
>To: <[e-mail]> <[e-mail]>
>Subject: Re: [TLS] padding bug
>
>Nikos Mavrogiannopoulos <[e-mail]> writes:
>
>>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.
>
>Before that, you'd have to present evidence that "all existing protocols
>do
>it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS
>doesn't,
>SSH doesn't, ... .  In fact of the major IETF application-level security
>protocols that I can think of, only IPsec does, and AFAIK (meaning based
>on
>long-ago discussions with one of the IPsec folks) that was done in order
>to
>fit the MAC into the fixed-size AH header (although there seems to be some
>disagreement on the details).
>
>As I've also already pointed out, TLS has for some years now provided for
>MAC
>truncation to a range of sizes.  If anyone's really worried about this,
>they
>can request truncation to whatever size they prefer.
>
>Peter.
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls
>