Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Wed, 13 July 2016 10:55 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 8CE8212D790 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 03:55:29 -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 i9fuvWNSXJaJ for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 03:55:27 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0091.outbound.protection.outlook.com [23.103.200.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E0B12D789 for <tls@ietf.org>; Wed, 13 Jul 2016 03:55:27 -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=2rB3g0PD7aB1L0ykSmPJjiRdJ1ZpN0qmba3SH9ju/wY=; b=IeLZEBWxWH1Pcc74UiJJQbGqf/pHZ8Xm8zfCo/ugxNrwuDBlEN5RdXHehwenYwopbLnbw2cDdQyqZtQrYCsnWeiiMUtwCxr5BnAsrt/fWiWfDMW3n64lWSS+QPz4hEJ7ihIBMf8K9KTANY0Hn85GTgNSSx7dXCPjJY01Kgss+ig=
Received: from BN1PR09MB0171.namprd09.prod.outlook.com (10.255.192.149) by BN1PR09MB0172.namprd09.prod.outlook.com (10.255.192.150) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 10:55:26 +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; Wed, 13 Jul 2016 10:55:25 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIAgABTxYD//9AKAIAAYosA//+/CYCAAEqKAP//wbAAAAq3xoAAGN/cgA==
Date: Wed, 13 Jul 2016 10:55:24 +0000
Message-ID: <D3AB940F.27C59%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> <D3AAA584.27BFA%qdang@nist.gov> <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk>
In-Reply-To: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@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: afdf1d07-cd67-4fbb-d9a8-08d3ab0c31ac
x-microsoft-exchange-diagnostics: 1; BN1PR09MB0172; 6:qm8of+KS7U6/D9i6SNvljE94Jx5qKG9CWAcvZNOoJ0GBUljWuiGw1bsPh79mczSdCA4zdCjyMX3bcQRL4ldBE/8O1AgE44WIj9SqyQGF2e3UDAAhC9Q4afMQYOt9498T9/OMCWCxPd1qt0c61Euq3K6vEtofmvrprnYAZMiIwhEqaCCnBx2FP6dv6oeDhrpS3iCVk8xqze7bA8hOH39Iu/5vX1/HLNyEXna/mIV+Y2ABPQLogTUx5saPQz7DvpHcemeM6/3yh/swaN7PNC9JsR3ocFpMz5cRS5s7In21VIjBP/irPayYpZQUX+n89Ilr+G4NGAhxGyjjdPM5kmgZ6g==; 5:PioaTPSr2yGaR6JeGV61DcU4CaFSrFvwQqr3tfhV+pPPP28fNrQIkrmBvHzLA37roQMXwdc7acWvMGkRkdYQUXI8zMZJxxRDA4icXwMqzbMBJDLP8248sUwgUnYCT/7uuylSQS6Dzse3axyPTcJIdQ==; 24:GVrgIoE4kDN/YEV2YjhbXZ0IP+S9aApOiMSANI2N9bT9mbPPYqu4h5eUqE+ysW0d5aMfkWfECvrS+F71C+iIyz8a5zV9SP5eQ91A8z8WxGo=; 7:fHi9ylOADLc4E/5I5rVdfBs++I1yeVdzeL1gVEJ7aBwTxZobETh41p813hKG4OCImvlUJ6uW+QaWJfuM/MKz59x1S4FuF78jAKCj/30z8lRtDs7hO9c0NMVftRtYNx2mv3Buo8/YibTP0lrtrm+7XuAoabpwaCDwSMIW1uNr/9Ta2AR37aY6ETN5J6Z3XkMG84Qlf3LFPXceP2EphJHFhgpQmrq3h3Qb09dlsUtSk3qtdZusJqcTiSoYM2oo0PKF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0172;
x-microsoft-antispam-prvs: <BN1PR09MB017267365867A09BDC14DBD3F3310@BN1PR09MB0172.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)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0172; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0172;
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(6116002)(102836003)(3846002)(87936001)(586003)(81166006)(8676002)(99286002)(81156014)(2906002)(8936002)(230783001)(3660700001)(3280700002)(10400500002)(86362001)(2900100001)(4326007)(19580405001)(19580395003)(93886004)(4001450100002)(106116001)(2950100001)(36756003)(105586002)(5001770100001)(66066001)(5002640100001)(68736007)(50986999)(83506001)(7736002)(7846002)(305945005)(97736004)(92566002)(54356999)(189998001)(8666005)(76176999)(106356001)(101416001)(4001350100001)(77096005)(122556002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0172; H:BN1PR09MB0171.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: <61504B300487DB4D92AB69B543F9F0C1@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 10:55:24.6049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0172
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FkJcaLAH3v40jhJBBjCdLNd7zCM>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Wed, 13 Jul 2016 10:55:29 -0000
Good morning Kenny, On 7/12/16, 3:03 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote: >Hi, > >> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) <quynh.dang@nist.gov> wrote: >> >> 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. > >Could you define "safe", please? Safe for what? For whom? > >Again, why are you choosing 2^-32 for your security bound? Why not 2^-40 >or even 2^-24? What's your rationale? Is it just finger in the air, or do >you have a threat analysis, or ...? I said it is safe because the chance of 1 in 4,294,967,296 practically does not happen. I am not interested in talking about other numbers and other questions. >> 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 please read a little further into the note that presents the >analysis: a conservative but generic approach dictates that, when the >attacker has multiple keys to attack, we should multiply the security >bounds by the number of target keys. > >A better analysis for AES-GCM may eventually be forthcoming but we don't >have it yet. > >>> 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? > >I'd love to have your answer to these questions. I didn't see one yet. >What is the cost metric you're using and how does it quantity for your >use cases? Again, I am not interested in other questions. I suggested the number about 2^38 records because it is a safe data bound because Eric put in his tls 1.3 draft the number 2^24.5 which is unnecessarily small. Your paper is a nice one which gives users good information about choices. > >Cheers, > >Kenny > >>> >>> Cheers, >>> >>> Kenny >> >> Regards, >> Quynh. Regards, Quynh. >> >> >> >>
- 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)
- 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
- [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- 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