Subject: Re: [TLS] padding bug

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Sep 2013 09:56:37 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>Why not protect against future key recovery attacks by truncating the MAC?
>After all IPSec does truncate the MAC to 96-bits for exactly the same reason
>(see RFC2104 Section 5: Truncated output). Using the existing good practices
>is a good thing.

IPsec's truncation has nothing to do with security, it was done in order to
fit the data into a 32-bit IP header boundary.  Since then an army of cargo-
cult standards designers has mindlessly copied this design artefact into who
knows how many other standards without understanding why it was done in the
first place.  It's not "good practice", it's cargo-cult standards design.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 Sep 2013 19:23:18 +0200

> first place.  It's not "good practice", it's cargo-cult standards design.

Do you have any reference for that? RFC2104 and the paper it
references claim otherwise.

regards,
Nikos

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 10 Sep 2013 13:36:21 -0400

On 9/10/13 13:23 , "Nikos Mavrogiannopoulos" <[email-masked]> wrote:

>> fit the data into a 32-bit IP header boundary.
>
>Do you have any reference for that? RFC2104 and the paper it references
>claim otherwise.

I participated in that discussion back then, and confirm that the big
reason for truncating the MAC was security: specifically achieving a good
balance between resistance to MAC forging attacks and resistance to key
recovery attacks.