IETF Logo Mail Archive

Re: [TLS] padding bug

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 24 September 2013 17:41 UTC

Return-Path: <Andrei.Popov@microsoft.com>
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 72AB821F90CC for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 10:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 p0qjLLWL3R3W for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 10:41:08 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id D626121F88B4 for <tls@ietf.org>; Tue, 24 Sep 2013 10:41:07 -0700 (PDT)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 17:40:59 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.130]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.130]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 17:40:59 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>, Hovav Shacham <hovav@cs.ucsd.edu>
Thread-Topic: [TLS] padding bug
Thread-Index: AQHOuUODka+JHcxaQ6OFXY9dkTUeRJnVFwgAgAANcOA=
Date: Tue, 24 Sep 2013 17:40:59 +0000
Message-ID: <abf83d95c8b544418115a5830a0127c9@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CAGAMPd_R-esTbs5d4QMkvmF3sFSA+Q7Wx9WPJhhZxZjm1W31SA@mail.gmail.com> <DDEEE6E9-3DCC-4F97-BF5D-EA517B4A88EF@ll.mit.edu>
In-Reply-To: <DDEEE6E9-3DCC-4F97-BF5D-EA517B4A88EF@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 09796A1B83
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(19300405004)(53806001)(76482001)(83072001)(76786001)(19580405001)(65816001)(19580395003)(83322001)(80976001)(74502001)(47446002)(76796001)(54356001)(77096001)(79102001)(56776001)(76576001)(74662001)(16236675002)(15202345003)(51856001)(59766001)(77982001)(31966008)(63696002)(56816003)(54316002)(15975445006)(19609705001)(50986001)(81686001)(47976001)(74706001)(46102001)(74876001)(74316001)(33646001)(80022001)(69226001)(49866001)(81816001)(74366001)(81542001)(47736001)(81342001)(4396001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB194; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_abf83d95c8b544418115a5830a0127c9BL2PR03MB194namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
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, 24 Sep 2013 17:41:12 -0000

I agree that an approach that deprecates known weak ciphers in favor of (currently deemed to be) strong ciphers is preferable. This is how the TLS protocol was designed to remain secure over time, and it does not rely on new, optional extensions.

Besides, has someone completed a thorough analysis of all existing TLS ciphers when used within the proposed "Encrypt-then-MAC" construction?

Cheers,

Andrei

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Blumenthal, Uri - 0558 - MITLL
Sent: Tuesday, September 24, 2013 9:41 AM
To: Hovav Shacham
Cc: tls@ietf.org
Subject: Re: [TLS] padding bug

On Sep 24, 2013, at 12:31 , Hovav Shacham <hovav@cs.ucsd.edu<mailto:hovav@cs.ucsd.edu>> wrote:


Peter Gutmann <pgut001 at cs.auckland.ac.nz<http://cs.auckland.ac.nz/>> writes:
It seems to be accepted by everyone except the WG chairs

I'm not thrilled with making changes to a fundamental part of the TLS design through an extension.  TLS is too complicated to analyze already; this doesn't help.

I would prefer an approach that deprecates existing suites in favor of non-CBC authenticated encryption modes.

I concur. Deprecate old, and require authenticated encryption.

v2.23.0 | Report a Bug | By Email