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