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

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Tue, 12 July 2016 17:56 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 3983312D59F for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:56:21 -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 MQxbhWSyXH1d for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:56:19 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3517312D5B0 for <tls@ietf.org>; Tue, 12 Jul 2016 10:56:19 -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=nkcb7dIZ7E9OvcV4HrgORgYvIFH4ammodee0+wHPPfM=; b=NYcm4sjv3egc9uZWoP8DdOC+aTfVO9yDHib518wMVLrgBcL3Jtp0jdDPhcvYlLQBNMTn1b/2+1NnDnuuHgTKDXERvSSMbx5K6oavPQa6VYqwA2aK/8j5aGhNQiDEXrUiYZnlYqWbR4JtMw0DrCjlO0kbEY5XWRxPHQ4jijwgrrA=
Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0170.namprd09.prod.outlook.com (10.255.192.148) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:56:17 +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:56:17 +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//+/CYCAAEqKAP//wbAA
Date: Tue, 12 Jul 2016 17:56:17 +0000
Message-ID: <D3AAA584.27BFA%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> <D3AA9C1C.27BA8%qdang@nist.gov> <D3AAE570.70A92%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D3AAE570.70A92%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: e946f395-7610-4a51-1db7-08d3aa7dd2e6
x-microsoft-exchange-diagnostics: 1; BN1PR09MB0170; 6:3eft2b9rGbBCb2Yn7L5vJOG+Cp2AvUqKhZGUbsqui4TV5RI7AWAlaxohKTEu33q6hxP5mu27sVVaPw0Ip+yVOj72x+LG81ztzVPyx6ga9nPnbT8/2BdspBx8rIOQiZlvN7HGCdvamT+F2U33OCL+Xg9zW9bWWp3CG9iixZ0+OWib8AlwMbXt8jPqRIzgsIDfrWllYm7Kbg6uPkRn/vp6cm6RwAJmJPQX/bR0nJvs3FYHIpMmByUBAOtkJitDdmj2YnzE9o/eNA+MGiAwbxeu6U85Po9fSyVx9GAy0+MKSzG3WBVS7K3VGw3JKyuvfcdxCd3h1VDpbHSUreT+wQxCFw==; 5:CxRK/2eBxXA8G3YJcgI9g0nX/NAAqmGwNDgUubI7TkP89zcWnxMsSuFK9RQH6bqav6TGdZpr2yjjvJKIqDu15NN3tEavkPDDalR9GuDKi47cxlDyrYfmB1PlWGnlQL3PHQ1omj4OtGQ7iuIEFyqKdA==; 24:1ntsgrteFhLUj7rBsqrwSuvrCVKWxDpswu3PqO2xi9369/pZDj607tyeFMtOuAqkcuRbi0tv/5SmDKWGybdH+jjYHB0t7otXKtSpMR1uR0c=; 7:hhX8BHSnFHAgAoMHziYaZwqHTJ7yWx3WY+MJNbJcGW3ysYZ89tLdSk6D7Nd3kwt5K0EflTHk2absgBni1cHY+PFzyGLsq9ro5oExTFds3l+ZU8y1sbGsGshRShMPh5JO0S2DNlc7WcNNadwNEBSlxWm2OVn6YzUPfpMlVdxR0koqtljYYyyWlWJs6i4hUAVD3rJtEiiZwexj6aW/R7d/Z+jkOeW7chhHHh2Una4fZJL+L1UV9TiJPXnbn3ihgO7h
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0170;
x-microsoft-antispam-prvs: <BN1PR09MB0170585488399953021269FEF3300@BN1PR09MB0170.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0170; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0170;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(3660700001)(19580395003)(54356999)(19580405001)(7846002)(7736002)(93886004)(2501003)(2906002)(305945005)(50986999)(106356001)(106116001)(76176999)(586003)(81156014)(81166006)(3280700002)(2900100001)(83506001)(2950100001)(101416001)(8666005)(36756003)(11100500001)(5001770100001)(92566002)(8676002)(122556002)(4001350100001)(3846002)(6116002)(102836003)(97736004)(68736007)(5002640100001)(107886002)(66066001)(189998001)(230783001)(10400500002)(87936001)(77096005)(99286002)(8936002)(86362001)(105586002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0170; 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="iso-8859-1"
Content-ID: <CF93E8B5348D5748990C18DEA2AE1F9E@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:56:17.1541 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0170
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iPIoXuG3afaPzrQE8Vj_dZLfm_0>
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:56:21 -0000

Hi Kenny, 

On 7/12/16, 1:39 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote:

>Hi
>
>On 12/07/2016 18:12, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote:
>
>>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,
>>>>
>>>>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.
>
>I would agree that it does not make sense to ask TLS peers to rekey
>unnecessarily. I also agree that 1 in 2^32 is
>1 in 4,294,967,296. Sure looks like a big, scary number, don't it?
>
>Are you then arguing that 2^{-32} for single key attacks is a big enough
>security margin because we want to avoid rekeying?

Because it is safe therefore there are no needs to rekey. I don¹t
recommend to run another function/protocol when there are no needs for it.
I don¹t see any particular reasons for mentioning single key in the
indistinguishability attack here.

>Then do you have a
>specific concern about the security of rekeying? I could see various ways
>in which it might go wrong if not designed carefully.
>
>Or are you directly linking a fundamental security question to an
>operational one, by which I mean: are you saying we should trade security
>for avoiding the "cost" of rekeying for some notion of "cost"? If so, can
>you quantify the cost for the use cases that matter to you?
>
>Cheers,
>
>Kenny 

Regards,
Quynh. 


>