Re: [TLS] padding bug

"Blumenthal, Uri - 0558 - MITLL" <> Tue, 24 September 2013 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80A5111E811F for <>; Tue, 24 Sep 2013 05:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.528
X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h7TJuww1xMSW for <>; Tue, 24 Sep 2013 05:48:48 -0700 (PDT)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 450EC11E8121 for <>; Tue, 24 Sep 2013 05:48:47 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id r8OCm6wZ025441; Tue, 24 Sep 2013 08:48:40 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <>
To: "''" <>, "''" <>
Date: Tue, 24 Sep 2013 08:48:32 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65IfHcVqqY2KB5QIOIiN5kL9FEAAAAmv0e
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-24_05:2013-09-23, 2013-09-24, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309240052
Message-Id: <>
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:48:52 -0000


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

TLS mailing list