Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Tue, 12 July 2016 17:12 UTC
Return-Path: <quynh.dang@nist.gov>
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 4B7D912D5A1 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 2sK75stf8hmP for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:12:35 -0700 (PDT)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0120.outbound.protection.outlook.com [23.103.201.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A42512D100 for <tls@ietf.org>; Tue, 12 Jul 2016 10:12:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vOcjdHxthvW/R+vlfUQIrjvfmO+3s4a6HHyiNCu1yvc=; b=jFpU4VE9hAIqVC4b7nOynbe+BFL53CR4GbeDyHGik7XeJBm10aFuz3KXQjuAnBNdgXC0cp92GKUcR+tIgw4aJhR0uFVDjwMkqS4+/yFkx2akvhn+F5lVBxlJvbfZr55V16QZy4rR0jFaw4H2FI+7H9Y6cLnek4BdWCyxhDqyYac=
Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:12:32 +0000
Received: from BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) by BN1PR09MB0171.namprd09.prod.outlook.com ([10.255.192.149]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:12:32 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, "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: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYA=
Date: Tue, 12 Jul 2016 17:12:32 +0000
Message-ID: <D3AA9C1C.27BA8%qdang@nist.gov>
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> <D3AADB49.70A35%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D3AADB49.70A35%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.105.150]
x-ms-office365-filtering-correlation-id: 0c202b72-50d2-43ac-a3d5-08d3aa77b64e
x-microsoft-exchange-diagnostics: 1; BN1PR09MB0171; 6:EWHRdY++dfHmctJ+e0DGQQvDHuSVFrICMPrOTqWEpTq2d9+WfMY6wfGE1Y50vkMxhMxnh+6085XeiUu3tJUgDYD77qay/i+fTIaAKuarVYUytLVQVjGITHW6Yqot2MsWUXXLH8n6GSYzz96a632uYYki+tan5cssVU6+3XZVaD5DGHVxOf6DRzw42IwvWK/F0vU7GoAMaNASkYEf27M+KJPvjHR7huexxI12qYST0Ci/uCtKrViNSLFzYJGYczQrYvkCkSYo8Y77UyqPNV9lgnRdiqhN/hzimU/4w2xjDnbsNdzCJ8iqXxX3b1a2oQnudXzdEu0dlautKOBmqIIfYg==; 5:xQPQF82Wn1MZRfSWVP2ZdmzlphuASZBkOskMo6wEl/kSyU2wesMoNgGY7Psp1rV0vBP0q/nInA750fd8DDrzrPn5dFCykS6bvJMFgU4GFVkh1el29RsY8pihaMMjPtElc2pRv6IFTY98VorhA329TA==; 24:iXbt09v2zy7VErFPYpcXzW/bxg8B2InHdh0kcOlOaqFp8gf/PgQYA9TYzq3NH6gxhKJ/6Rpdvyc9nVsMjOMEKLG1kb59bNpV5DGapVOZ7Xg=; 7:uBizh9EgXxzPRpdL9mqiZ0L5SF3vK/Vbpiv7a8peDYZ+2ReH6jXZoTZaRYcwQj265Ff8uKWXJv/ok4giLxQGmECppH37x4+eiaePH79LzVcJ+1X/GubTEOgAOmYgPE3aF7sr850p4xi4W+mOrBaKcQm7zqOuW/08B9bEpiErmmyU63qDUgDJezEdvVpfUl49h3bKHz7O9vEQP+q/HZWy2zzmaa4arNRP6EPoJbCGHhqK6+LvagBoG1duZM8IDcuO
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0171;
x-microsoft-antispam-prvs: <BN1PR09MB01711D7F12394191AFE689E0F3300@BN1PR09MB0171.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0171; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0171;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(55674003)(8936002)(3280700002)(36756003)(87936001)(10400500002)(97736004)(83506001)(230783001)(66066001)(3660700001)(8676002)(19580405001)(2906002)(86362001)(81166006)(81156014)(105586002)(99286002)(106116001)(106356001)(7846002)(2950100001)(68736007)(2900100001)(107886002)(305945005)(7736002)(11100500001)(19580395003)(189998001)(50986999)(54356999)(76176999)(2501003)(101416001)(586003)(92566002)(5001770100001)(102836003)(122556002)(3846002)(5002640100001)(93886004)(6116002)(77096005)(15975445007)(4001350100001)(8666005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0171; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="euc-kr"
Content-ID: <E31966D574F3844C8C0BCC1D335FA7E2@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:12:32.0377 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0171
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/37TC_sXgr5PJj-Y9SWCLrMA-qoE>
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 17:12:42 -0000
Hi Kenny, On 7/12/16, 1:05 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote: >Hi > >On 12/07/2016 16:12, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote: > >>Hi Kenny, >> >>The indistinguishability-based security notion in the paper is a stronger >>security notion than the (old) traditional confidentiality notion. > >Well, indeed, I'm somewhat aware of the notion and its emergence over the >years. Indeed, I have had the very real pleasure of writing a few research >papers using indistinguishability-based security notions! Resisting the >temptation to give you chapter and verse on your analysis of the notions >and how to interpret them... > >> >>(*) 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. > >OK, I think now we are at the heart of your argument. You support our >choice of security definition and method of analysis after all. > >And we can agree that good descriptions can only help. > >>That is why I support the limit around 2^38 records. > >I don't see how changing 2^24.5 (which is in the current draft) to 2^38 >provides a better description to users. > >Are you worried they won't know what a decimal in the exponent means? > >Or, more seriously, are you saying that 2^{-32} for single key attacks is >a big enough security margin? If so, can you say what that's based on? It would not make sense to ask people to rekey unnecessarily. 1 in 2^32 is 1 in 4,294,967,296 for the indistinguishability attack. >Cheers, > >Kenny Regards, Quynh. > > > >> >>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. >>>> >>>> >>>> >>>> >>>> >>> >> >
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Peter Gutmann
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Watson Ladd
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Hubert Kario
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dave Garrett
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny