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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Tue, 12 July 2016 19:03 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 4D0F912D5D8 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 12:03:15 -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_H3=-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 N05B8jAiYcFC for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 12:03:14 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0043.outbound.protection.outlook.com [104.47.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F7C12D5C3 for <tls@ietf.org>; Tue, 12 Jul 2016 12:03:11 -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=133Vvxr/aZAkeub5fAj/7x8VqwnH7khIK08bNhp+2Yc=; b=qmvX/QN33OE7wnsdMxeJJ4oSHiCEib41ZMkPdtjZYDyAEAkPkbPA95+O91BnVAFaFMeRvSPhd5TC31O/OBZnvz2eOWd6G/lKJxuzyuju34pQwYWRW5T05A9kBLOhh0QDe2u4WXgHQQdoXp2Hz6UadUY/RI0ZDj1WBqISodJFRCs=
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 19:03:07 +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 19:03:07 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA///wrQCAABjmgP//81OAgAASrf4=
Date: Tue, 12 Jul 2016 19:03:07 +0000
Message-ID: <60BA093E-2B35-4F88-B6E1-81113CC27AA8@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> <D3AADB49.70A35%kenny.paterson@rhul.ac.uk> <D3AA9C1C.27BA8%qdang@nist.gov> <D3AAE570.70A92%kenny.paterson@rhul.ac.uk>,<D3AAA584.27BFA%qdang@nist.gov>
In-Reply-To: <D3AAA584.27BFA%qdang@nist.gov>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-originating-ip: [78.146.50.187]
x-ms-office365-filtering-correlation-id: 1c38db1f-a3f1-4d63-d2f6-08d3aa872939
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:d9eCTs/5P0w3bBjolLe07zRZ0MFrFpSaye5KQthKk6zAlulblSlzFEgRqCmU7oXAOREd8M6kHXtE8ekvM0YHOnOSqBte6b/WYTXkvXo/OsqN5IEEO4YQpCKRwk4cZhITIZeO+9LX6b2NDp4K7Q+9oMXzTtxDHJUtnYYWz+UAg2anwRjlIcMjvWg6+fOo0jKML7CISYsTX3byLgbJT9bC/BqK4GMBGo6axGTojRh9gzKfdKtDJrRxnsX73fAcAu+KZ2/TTBkAfRLVwZ4dn6O8/bbn/Z8dvI9sFgXLo4RYJ54=; 5:pyUt9H1a3T5lUeAzu4VL+V7AbzGzdZnXaib/idhQdhLDhROEMq8F8yBckd9npNSNEodhboT+xQ++hUULi52fE4cJO/O7DVTcJ0k+CEsw5CjV1rlx33iuLTc9aIoMRnExWiyuoH8N0SX+6Yzu/hTj4w==; 24:NFxlnHMf3OLO/uiQCIBk0zxHwkbOpQu9taStClsu5m8N5s9mdxmmRrMmscCcfG1OOnZDHDh2+zDinHd7E60x5LyeOaRiHsqEifFVdrmJs2c=; 7:Hwqar11YM9jEwDBTZch8wUta3s5J8E3l/7x75VOf0ra+O0T0laPsTljpvrbej+VSbVAneF2AYnQaWL58LOq6tphN265o7Y5BLt6T7S8J7VHBuPyGxRj7HN2R7Id+nC4TgqqDz7N49FXxIpCN6IZ2c3o+Oz+xrxclvJNQJEmeC2PRsPIm/JoIc2DTR+jKPPI3rdUikVPM0FKwRi+9efTroIEhhlTXUJ49Xn9CNJ2LoQiW3+nREhDhWMS4gF46PVdv
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822;
x-microsoft-antispam-prvs: <VI1PR03MB1822314E64D5673AA611FAD8BC300@VI1PR03MB1822.eurprd03.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); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(377454003)(305945005)(66066001)(36756003)(81166006)(2950100001)(2900100001)(54356999)(76176999)(50986999)(8666005)(101416001)(7736002)(74482002)(8936002)(7846002)(82746002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(230783001)(106116001)(2906002)(83716003)(6116002)(106356001)(68736007)(102836003)(3846002)(87936001)(68196006)(105586002)(4326007)(86362001)(3280700002)(110136002)(10400500002)(3660700001)(33656002)(189998001)(11100500001)(97736004)(93886004)(8676002)(5002640100001)(586003)(7059030)(104396002); 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 19:03:07.6842 (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/LyEQRxWPxh-yrCnk-MLdJo3M03s>
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: Tue, 12 Jul 2016 19:03:15 -0000

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

Cheers,

Kenny

>> 
>> Cheers,
>> 
>> Kenny
> 
> Regards,
> Quynh. 
> 
> 
>