Subject: Re: [TLS] padding bug

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Sep 2013 12:31:12 +0000

Nikos Mavrogiannopoulos <[email-masked]> 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.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 24 Sep 2013 08:48:32 -0400

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: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
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:[email-masked]]
Sent: Tuesday, September 24, 2013 08:31 AM
To: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] padding bug

Peter.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 24 Sep 2013 12:59:37 +0000

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" <[email-masked]>
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.
>

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 24 Sep 2013 09:00:54 -0700

Peter Gutmann wrote:
> 
> TLS has for some years now provided for MAC truncation to a
> range of sizes.

I believe you are confusing the max_fragment_length extension
with truncated_hmac.  Truncated HMAC provides only one size,
80 bits, with the motivation being bandwidth constraints.

Mike

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 24 Sep 2013 14:17:41 -0400

> 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.

​Just to set the historical record straight:

​The motivation for HMAC truncation in IPsec was saving some dummy padding
to obtain 32- and 64-bit alignments (in IPsec headers).​

Once the benefit of such truncation for alignment purposes was identified,
a long debate took place regarding the security risks or benefits of HMAC
truncation. We eventually converged to the consensus that truncation posed
no known risks to HMAC and, moreover, the work of Preneel and van Oorschott
showed that in some cases it may even add to security. This led to IPsec
adopting truncated HMAC and also motivated the paragraph on truncated HMAC
in RFC 2104.

Since then there has been no significant new evidence supporting truncation
or non-truncation. In particular, the prevalent use of HMAC as a PRF (not
just MAC), also in TLS, assumes security for both truncated and
non-truncated HMAC.

One thing is for sure: The decision to truncate a MAC must be done on a
per-algorithm basis. For some MAC algorithms it may be fine to do so, for
others it may not.

Hugo

​PS: Historians may want to consult OLD IPsec archives, for example
www.vpnc.org/ietf-ipsec/96.ipsec/msg00001.html ​

On Tue, Sep 24, 2013 at 8:48 AM, Blumenthal, Uri - 0558 - MITLL <
[email-masked]> wrote:

> ​​
> ​​
> 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.
>