Re: [TLS] padding bug

"Paterson, Kenny" <> Tue, 24 September 2013 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2E6421F9228 for <>; Tue, 24 Sep 2013 05:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Usq0XdB+vjQf for <>; Tue, 24 Sep 2013 05:59:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2D4421E8063 for <>; Tue, 24 Sep 2013 05:59:42 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 24 Sep 2013 12:59:41 +0000
Received: from mail74-am1 (localhost []) by (Postfix) with ESMTP id B2B571000CD; Tue, 24 Sep 2013 12:59:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: PS-31(zzbb2dI98dI9371I1431J542I1432I12d5I14ffIzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz31iz1de098h1033IL17326ah1de097h186068h5eeeK8275dhz2dh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(479174003)(24454002)(189002)(51704005)(53754006)(243025003)(199002)(48214007)(51694002)(81816001)(15202345003)(76176001)(81686001)(80976001)(74662001)(83072001)(76786001)(74482001)(56776001)(54316002)(76482001)(74366001)(74876001)(47446002)(76796001)(74502001)(51856001)(47736001)(47976001)(50986001)(49866001)(4396001)(46102001)(19580405001)(19580395003)(31966008)(83322001)(36756003)(56816003)(15975445006)(83506001)(79102001)(69226001)(80022001)(66066001)(81542001)(65816001)(53806001)(74706001)(63696002)(81342001)(54356001)(77982001)(59766001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB280;; CLIP:; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail74-am1 (localhost.localdomain []) by mail74-am1 (MessageSwitch) id 1380027579745469_13599; Tue, 24 Sep 2013 12:59:39 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id A1B084A0246; Tue, 24 Sep 2013 12:59:39 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 24 Sep 2013 12:59:39 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 12:59:39 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 12:59:38 +0000
Received: from ([]) by ([]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 12:59:38 +0000
From: "Paterson, Kenny" <>
To: "Blumenthal, Uri - 0558 - MITLL" <>, "''" <>, "''" <>
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65IfHcka+JHcxaQ6OFXY9dkTUeRAAAm4UAAASTYYA=
Date: Tue, 24 Sep 2013 12:59:37 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-forefront-prvs: 09796A1B83
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 12:59:51 -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:

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:

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



On 24/09/2013 13:48, "Blumenthal, Uri - 0558 - MITLL" <>

>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>
>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: <>
>Lexington, MA  02420-9185
>MIT LL Root CA: 
> <>
>DSN:   478-5980 ask Lincoln ext.1638
>----- Original Message -----
>From: Peter Gutmann []
>Sent: Tuesday, September 24, 2013 08:31 AM
>To: <> <>
>Subject: Re: [TLS] padding bug
>Nikos Mavrogiannopoulos <> writes:
>>Since you are the one claiming that MAC truncation isn't necessary when
>>existing protocols do it (even TLS does it on the Finished message MAC),
>>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
>it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS
>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
>long-ago discussions with one of the IPsec folks) that was done in order
>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
>truncation to a range of sizes.  If anyone's really worried about this,
>can request truncation to whatever size they prefer.
>TLS mailing list
>TLS mailing list