IETF Logo Mail Archive

Re: [TLS] padding bug

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 10 September 2013 09:56 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 0441421E811D for <tls@ietfa.amsl.com>; Tue, 10 Sep 2013 02:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 2P7Skngd83jK for <tls@ietfa.amsl.com>; Tue, 10 Sep 2013 02:56:44 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7921E811E for <tls@ietf.org>; Tue, 10 Sep 2013 02:56:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378807000; x=1410343000; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tU0nmhSV9qCvmvQKNunw7flAAii2HqOYXNvudbz8QRc=; b=R4rB9CkU8Q7kdwjF2jzXpunsO6gqBhpFuG+s/otOZId3k9ZgwyUm0cCJ GQOae0vCbC1vdK9zPQYlaqSDkdiwEEncwgUB2juxD0eirmHUnbUqWAjh+ l1y31Jge+YQFs7CgeSVfWW0WEr9kvCYjOUSnetMyC3v6pcEXfdVddPLAn U=;
X-IronPort-AV: E=Sophos;i="4.90,877,1371038400"; d="scan'208";a="211423830"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Sep 2013 21:56:38 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 21:56:37 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "nmav@gnutls.org" <nmav@gnutls.org>, "benl@google.com" <benl@google.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6uDAn11t03FwJUSQ2YNO6dq4H0sQ==
Date: Tue, 10 Sep 2013 09:56:37 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566C373@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 09:56:58 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> 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.

v2.23.0 | Report a Bug | By Email