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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 16 March 2016 18:14 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 5D92212D616 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BX4zjKIwcyr for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:14:43 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0042.outbound.protection.outlook.com [104.47.2.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08FA12DA4C for <tls@ietf.org>; Wed, 16 Mar 2016 11:14:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; 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 DB5PR03MB1813.eurprd03.prod.outlook.com (10.166.171.146) by DB5PR03MB1816.eurprd03.prod.outlook.com (10.166.171.149) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:14:38 +0000
Received: from DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) by DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 18:14:38 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= <colm@allcosts.net>, "tls@ietf.org" <tls@ietf.org>
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: <D30F5033.66E40%kenny.paterson@rhul.ac.uk>
References: <CAAF6GDekw3stfYGd1q+Zzde--g5M0h9ZTWrVLVJxEwp+frQTHQ@mail.gmail.com>
In-Reply-To: <CAAF6GDekw3stfYGd1q+Zzde--g5M0h9ZTWrVLVJxEwp+frQTHQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [92.3.218.210]
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: <DB5PR03MB18169C4DC20EDEBC8A03D924BC8A0@DB5PR03MB1816.eurprd03.prod.outlook.com>
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; H:DB5PR03MB1813.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <2D465DAF93D4724998A77D9E98EFDCFF@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
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: <http://mailarchive.ietf.org/arch/msg/tls/O9tI0HSoykLt5OriQLtymq4Tnto>
Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Mar 2016 18:14:53 -0000

Hi Colm,

On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh"
<tls-bounces@ietf.org on behalf of colm@allcosts.net>; wrote:
>
>This has been bugging me for a long time and I've talked to some here
>about it in person, but this report;
>
>https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upt
>urn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf
>
>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:
>https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13
> , 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:
http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram
-tls).

- 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
(https://eprint.iacr.org/2015/1129). The initial patch to the code was
also insecure (https://eprint.iacr.org/2015/1241). 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:

https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02


Cheers

Kenny 

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