Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Tue, 12 July 2016 16:33 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 6505012D550 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 09:33:07 -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_H4=-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 l8AyVw0sCWqI for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 09:33:04 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50066.outbound.protection.outlook.com [40.107.5.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2C912D549 for <tls@ietf.org>; Tue, 12 Jul 2016 09:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pO5XCHZu4GzIjTFCO3dwQBGTdCQE4DYq2MymEbf3qIo=; b=vcJ7Fydikwp4SdQxDRFRT8HA18gL/MyIxJpmpju050Ybmu/eLomehX5SQ/5cWRCNDtU7/ncUO4MQUuDaR79ucls3Yq3zegV5Yi86vkmgKC6DipJej8ZWmt1yTouCJZ0yxgRfN4C1nygUazXr/iPXi9YTrlqxGYxqRHk5DZ7VG3M=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 16:33:00 +0000
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 16:33:00 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "Dang, Quynh (Fed)" <quynh.dang@nist.gov>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAACUMAgAAetIA=
Date: Tue, 12 Jul 2016 16:33:00 +0000
Message-ID: <D3AAD721.70A11%kenny.paterson@rhul.ac.uk>
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <D3AA5BD6.27AC0%qdang@nist.gov> <D3AAB674.709EA%kenny.paterson@rhul.ac.uk> <D3AA7549.27B09%qdang@nist.gov> <d1f35d74e93b4067bf17f587b904ebff@XCH-RTP-006.cisco.com>
In-Reply-To: <d1f35d74e93b4067bf17f587b904ebff@XCH-RTP-006.cisco.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.5.160527
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.227.30]
x-ms-office365-filtering-correlation-id: 93cad754-6898-4503-ab6c-08d3aa7230a0
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:I1i+unVw7BO9g8kCMuWNy8QDS9oK1qFrNt41L4GdTNFqMEVMauP3OeBO2imZnAfuuNhBRJzzPVG6mxvzbX2LxOe2t07DVdcsrGWhRsUY9vsESYYleaTzGwoWMuNmRavk66UC+rJao/04ehCFPpCf6Iyb645Nx0lyBj3NF/6BFzgmLRbaferopTBakiFGG/FCtITdeobRRKH9OgT+L15dA2cEcDK34D/8N6EY5lJbZqJoACbKchH8khqfPyZ9Gp//PdwtvAJ74uTHfh8/L6UvE8S+kXa4hCPvqvvrn7OlFAg=; 5:0RU3ns+BxZBEQDF076wwOBGQt6Ow/k7Nm5lRWb2VpUjidsExymO1ZkNsXfTf9/vh+RbWh/hlkwGS06XGX9Qku80BdeZXHgFEFNN93yMZv0hEvm5R4TcRmwv0U1UiUG9TAJCxy+R/82TrvJizK6IMxw==; 24:oC9tBczyg1MmTnUUs6GEHHLpcKd/1IfnDAfYHEJ7cB9qVK/GcsnzP20kj9NtPMhdbboQg/cD5aclVgFknXdfmwT/+t1kZV8JjnZIo4DzL3U=; 7:RIMxHHIZXu9oGL7aDegi45rby/27Cnb+iNRQ9tr0rRQBNohw/4MYJ28zfb/aWD2wR8Dy4neMwdgHRwNvoWlLnxiKD2PKyZi5hmVabBxxFyUtC0eKuYmCUclrsmY5QcJ0s4QObQf8KfUsPz7GiCIdbyOlQpoeWWbw/2Ba+Q7e90ehf2jbIeP3i2csA/TSiqO8yZ/EYwH8ao0aHT0ZQiECYmQEnPGhpogKNnByb2BTAaeW0fJ+AH25H4fTccPfQWsQ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822;
x-microsoft-antispam-prvs: <VI1PR03MB1822E5503C665CCEA0FAB520BC300@VI1PR03MB1822.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(55674003)(189002)(199003)(377454003)(13464003)(101416001)(66066001)(305945005)(36756003)(81166006)(8666005)(2950100001)(15975445007)(2900100001)(54356999)(76176999)(50986999)(7736002)(74482002)(8936002)(2501003)(83506001)(7846002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(3846002)(230783001)(106116001)(2906002)(6116002)(68736007)(106356001)(102836003)(87936001)(105586002)(86362001)(3280700002)(107886002)(10400500002)(3660700001)(5001770100001)(97736004)(189998001)(11100500001)(4001350100001)(93886004)(8676002)(5002640100001)(586003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <03E0CE73FCBBAA4B9B08081EAD47F15F@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 16:33:00.6960 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Eo1hSaQq467WIz8vue67I_0aKrc>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
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: Tue, 12 Jul 2016 16:33:07 -0000

Unfortunately, that's not quite the right interpretation. The bounds one
obtains depend on both the total amount of data encrypted AND the number
of encryption queries the adversary is allowed to make to AES-GCM under
the (single) target key.

We assumed each record was 2^14 bytes in size to simplify the ensuing
analysis, and to enable us to focus on how the security bounds then depend
on the number of records encrypted. See equation (5) and Table 2 in the
note at 

	http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf.

In short, the security bound does not necessarily hold for ANY 2^52
encrypted data bytes. For example, if the attacker encrypted 2^52 records
of size 1 (!) then equation (5) would tell us almost nothing useful at all
about security.

Finally, you write "to come to the 2^38 record limit, they assume that
each record is the maximum 2^14 bytes". For clarity, we did not recommend
a limit of 2^38 records. That's Quynh's preferred number, and is
unsupported by our analysis.

Cheers,

Kenny 


On 12/07/2016 16:45, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> wrote:

>Actually, a more correct way of viewing the limit would be 2^52 encrypted
>data bytes. To come to the 2^38 record limit, they assume that each
>record is the maximum 2^14 bytes.  Of course, at a 1Gbps rate, it'd take
>over a year to encrypt that much data...
>
>> -----Original Message-----
>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dang, Quynh (Fed)
>> Sent: Tuesday, July 12, 2016 11:12 AM
>> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org
>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
>> 
>> Hi Kenny,
>> 
>> The indistinguishability-based security notion in the paper is a
>>stronger
>> security notion than the (old) traditional confidentiality notion.
>> 
>> 
>> (*) Indistinguishability notion (framework) guarantees no other attacks
>>can
>> be better than the indistinguishability bound. Intuitively, you can¹t
>>attack if
>> you can¹t even tell two things are different or not. So, being able to
>>say two
>> things are different or not is the minimal condition to lead to any
>>attack.
>> 
>> The traditional confidentiality definition is that knowing only the
>>ciphertexts,
>> the attacker can¹t know any content of the corresponding plaintexts
>>with a
>> greater probability than some value and this value depends on the
>>particular
>> cipher. Of course, the maximum amount of data must not be more than
>> some limit under a given key which also depends on the cipher.
>> 
>> For example, with counter mode AES_128, Let¹s say encrypting 2^70 input
>> blocks with a single key. With the 2^70 ciphertext blocks alone (each
>>block is
>> 128 bits), I don¹t think one can find out any content of any of the
>>plaintexts.
>> The chance for knowing any block of the plaintexts is
>> 1/(2^128) in this case.
>> 
>> I support the strongest indistinguishability notion mentioned in (*)
>>above,
>> but in my opinion we should provide good description to the users.
>> That is why I support the limit around 2^38 records.
>> 
>> Regards,
>> Quynh.
>> 
>> On 7/12/16, 10:03 AM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
>> wrote:
>> 
>> >Hi Quynh,
>> >
>> >This indistinguishability-based security notion is the confidentiality
>> >notion that is by now generally accepted in the crypto community.
>> >Meeting it is sufficient to guarantee security against many other forms
>> >of attack on confidentiality, which is one of the main reasons we use
>>it.
>> >
>> >You say that an attack in the sense implied by breaking this notion
>> >does not break confidentiality. Can you explain what you mean by
>> >"confidentiality", in a precise way? I can then try to tell you whether
>> >this notion will imply yours.
>> >
>> >Regards
>> >
>> >Kenny
>> >
>> >On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)"
>> ><tls-bounces@ietf.org on behalf of quynh.dang@nist.gov> wrote:
>> >
>> >>Hi Eric and all,
>> >>
>> >>
>> >>In my opinion, we should give better information about data limit for
>> >>AES_GCM in TLS 1.3 instead of what is current in the draft 14.
>> >>
>> >>
>> >>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf,  what
>> >>is called confidentiality attack is the known plaintext
>> >>differentiality attack where  the attacker has/chooses two plaintexts,
>> >>send them to the AES-encryption oracle.  The oracle encrypts one of
>> >>them, then sends the ciphertext to the attacker.  After seeing the
>> >>ciphertext, the attacker has some success probability of telling which
>> >>plaintext  was encrypted and this success probability is in the column
>> >>called ³Attack Success Probability² in Table 1.  This attack does not
>> >>break confidentiality.
>> >>
>> >>
>> >>If the attack above breaks one of security goal(s) of your individual
>> >>system, then making success probability of that attack at 2^(-32) max
>> >>is enough. In that case, the Max number of records is around 2^38.
>> >>
>> >>
>> >>
>> >>
>> >>Regards,
>> >>Quynh.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>Date: Monday, July 11, 2016 at 3:08 PM
>> >>To: "tls@ietf.org" <tls@ietf.org>
>> >>Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt
>> >>
>> >>
>> >>
>> >>Folks,
>> >>
>> >>
>> >>I've just submitted draft-ietf-tls-tls13-14.txt and it should show up
>> >>on the draft repository shortly. In the meantime you can find the
>> >>editor's copy in the usual location at:
>> >>
>> >>
>> >>  http://tlswg.github.io/tls13-spec/
>> >>
>> >>
>> >>The major changes in this document are:
>> >>
>> >>
>> >>* A big restructure to make it read better. I moved the Overview
>> >>  to the beginning and then put the document in a more logical
>> >>  order starting with the handshake and then the record and
>> >>  alerts.
>> >>
>> >>
>> >>* Totally rewrote the section which used to be called "Security
>> >>  Analysis" and is now called "Overview of Security Properties".
>> >>  This section is still kind of a hard hat area, so PRs welcome.
>> >>  In particular, I know I need to beef up the citations for the
>> >>  record layer section.
>> >>
>> >>
>> >>* Removed the 0-RTT EncryptedExtensions and moved ticket_age
>> >>  into the ClientHello. This quasi-reverts a change in -13 that
>> >>  made implementation of 0-RTT kind of a pain.
>> >>
>> >>
>> >>As usual, comments welcome.
>> >>-Ekr
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>* Allow cookies to be longer (*)
>> >>
>> >>
>> >>* Remove the "context" from EarlyDataIndication as it was undefined
>> >>  and nobody used it (*)
>> >>
>> >>
>> >>* Remove 0-RTT EncryptedExtensions and replace the ticket_age
>> >>extension
>> >>  with an obfuscated version. Also necessitates a change to
>> >>  NewSessionTicket (*).
>> >>
>> >>
>> >>* Move the downgrade sentinel to the end of ServerHello.Random
>> >>  to accomodate tlsdate (*).
>> >>
>> >>
>> >>* Define ecdsa_sha1 (*).
>> >>
>> >>
>> >>* Allow resumption even after fatal alerts. This matches current
>> >>  practice.
>> >>
>> >>
>> >>* Remove non-closure warning alerts. Require treating unknown alerts
>> >>as
>> >>  fatal.
>> >>
>> >>
>> >>* Make the rules for accepting 0-RTT less restrictive.
>> >>
>> >>
>> >>* Clarify 0-RTT backward-compatibility rules.
>> >>
>> >>
>> >>* Clarify how 0-RTT and PSK identities interact.
>> >>
>> >>
>> >>* Add a section describing the data limits for each cipher.
>> >>
>> >>
>> >>* Major editorial restructuring.
>> >>
>> >>
>> >>* Replace the Security Analysis section with a WIP draft.
>> >>
>> >>
>> >>(*) indicates changes to the wire protocol which may require
>> >>implementations
>> >>    to update.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls