Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

"Paterson, Kenny" <> Wed, 16 March 2016 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D92212D616 for <>; Wed, 16 Mar 2016 11:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7BX4zjKIwcyr for <>; Wed, 16 Mar 2016 11:14:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A08FA12DA4C for <>; Wed, 16 Mar 2016 11:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1d/sdT6MtTCTNO1DSSBxmy3qXqdc7hjeiXIqL0nPWs4=; b=EcL5Hg4wtSqd3H5CWwnjKY43ds2+puaP2D9/aNHhfz634uVFwZEszUX11rRsIWXx+dkufwzOj5wE5MGyq7fcpPs6m4aDGTLiJ7XEZ0FeCwhi3dd9p6T6j4cELVpyisJU9zDT8h8s8PDhdfZKqlTpNnBZdcWDlSyevhPV1ztRwVU=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:14:38 +0000
Received: from ([]) by ([]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 18:14:38 +0000
From: "Paterson, Kenny" <>
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= <>, "" <>
Thread-Topic: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?
Thread-Index: AQHRf6+zYJzUjAAwo0ueTshDRg0uoQ==
Date: Wed, 16 Mar 2016 18:14:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: fbb74fc8-d1e9-4220-3cad-08d34dc6d631
x-microsoft-exchange-diagnostics: 1; DB5PR03MB1816; 5:2Dpx9DYQCCJIS4Gqd2MAxx2se+x115A17pW7hJz21h8cYdj48tPuK/p5zzN5I/iFSkW8r12teg+SKOVjl9aQ3TbIj002LEdWNsGNlWAKtmixAYGvwNMNKmTKgKd9E6kg7c+Lxls3muJbb1HDbSh6aA==; 24:znbn3EKSO9XxKHfSPPPhi9/dAWmE/8c74clnuWZWZaSuhPwo4gR0RfRHI8w1wex4HlIEKhQwBBzotb74l2fANJNbdfbxipuJzFqFvboSroQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB1816;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR03MB1816; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1816;
x-forefront-prvs: 08831F51DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(92566002)(87936001)(86362001)(2420400007)(74482002)(122556002)(3846002)(6116002)(102836003)(19580405001)(19580395003)(83506001)(1096002)(1220700001)(54356999)(2906002)(76176999)(5004730100002)(11100500001)(10710500007)(50986999)(4001350100001)(66066001)(2900100001)(1720100001)(15975445007)(10400500002)(2501003)(106116001)(5008740100001)(81166005)(3280700002)(15650500001)(77096005)(586003)(107886002)(5001770100001)(5002640100001)(189998001)(3660700001)(36756003)(7110500001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1816;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:14:38.0223 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1816
Archived-At: <>
Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?
X-Mailman-Version: 2.1.17
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: Wed, 16 Mar 2016 18:14:53 -0000

Hi Colm,

On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh"
< on behalf of> wrote:
>This has been bugging me for a long time and I've talked to some here
>about it in person, but this report;
>provokes me to bring it up. Here's the crux of it; is it really a
>security win to recommend the AEAD cipher suites for TLS 1.2 users?
>The AEAD cipher suites as-implemented are byte-for-byte mappable to
>response sizes, with no padding for any kind of length hiding. This makes
>passive size analysis attacks quite a lot easier than they could be (a
>quick sample of wikipedia page sizes suggests
> that even 16 byte blocks raise the difficulty by orders of magnitude).
>The search hints attack outline in the paper may not even work with
>16-byte padding. I want to emphasize that the attack here is passive,
>undetectable to servers or clients, and realistic
> - it's likely happening today.
>On the other side of the trade-off is that the AEAD mode ciphers are not
>susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago I
>wrote up some detail on the Lucky13 attack:
> , and my take here is that the scenario is so unrealistic that the
>attack is simply impractical against TLS - even unmitigated. In any
>event, TLS CBC implementations have been mitigated and patched. Here I
>also want to emphasize that the attack is active -
> it generates lots of noisy signals - and may never have happened.

Well, you know already that we disagree on this :-)

For everyone else's benefit, let me say the following:

- Attacks only ever get better.

- The Lucky 13 timing signal can be amplified for DTLS using packet trains
(see this NDSS 2012 paper for the techniques:

- As your blog nicely explains, AWS's s2n implementation chose to mitigate
Lucky 13 using a bespoke solution. This code was found to be vulnerable to
attack shortly after the code was released
( The initial patch to the code was
also insecure ( Readers can draw their
own conclusions from this. Mine is that even gifted programmers get TLS's
MtE construction wrong.

I feel strongly that going back to MtE would be a retrograde step.

Much better would be implementing an optional padding feature for the AEAD
modes. Something like this draft proposes:



>Is it wise to make the real-world attack cost less, to mitigate the
>theoretical one? I also think AEAD mode is awesome: it's how crypto
>should be used, and want to give it a strong endorsement, but not at the
>cost of making on-the-wire data meaningfully
> less secure. 
>At a minimum: could we agree that if a service/site is sensitive to
>privacy - it's reasonable for them to prefer AES-CBC; should they be
>penalized in SSL health analysis tools/reports for that configuration?
>it's not as flexible or useful as the padding
> in TLS1.3, but it's what we have.