IETF Logo Mail Archive

Re: [TLS] padding bug

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Tue, 10 September 2013 17:37 UTC

Return-Path: <prvs=296557a8eb=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0659A21E811D for <tls@ietfa.amsl.com>; Tue, 10 Sep 2013 10:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsLpzobUA6hg for <tls@ietfa.amsl.com>; Tue, 10 Sep 2013 10:37:02 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7721E8166 for <tls@ietf.org>; Tue, 10 Sep 2013 10:36:57 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8AHU8Qs026836; Tue, 10 Sep 2013 13:36:46 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 10 Sep 2013 13:36:21 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6uTEZTB+tnxvvZR16glBwfnj2LoA==
Message-ID: <CE54CFFD.10F7A%uri@ll.mit.edu>
In-Reply-To: <CAJU7za+nOxGsuQvaNedvYKQGyJYpaMcnv3kwbAwCiyZ6o7Yk4w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3461664981_56613"
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-10_08:2013-09-10, 2013-09-10, 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-1309100105
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 17:37:08 -0000

On 9/10/13 13:23 , "Nikos Mavrogiannopoulos" <nmav@gnutls.org> wrote:

>On Tue, Sep 10, 2013 at 11:56 AM, Peter Gutmann
><pgut001@cs.auckland.ac.nz> wrote:
>
>>>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.
>
>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.

v2.23.0 | Report a Bug | By Email