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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 13 July 2016 18:04 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 8A1E412D103 for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 11:04:45 -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=unavailable 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 cPmPdP6NJRsF for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 11:04:44 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0062.outbound.protection.outlook.com [104.47.2.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E736712B03C for <tls@ietf.org>; Wed, 13 Jul 2016 10:57:12 -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=3z1AwFp4qTie23FK0TJ3SILK64l56/PIH1YInIr+RZo=; b=zWSoMK0Tppv/amKhqHUsKB3lXhGKpkR8SAagCbL+5OJX531HX1zDJ7beWblYK1N4UWgXxJ7JEHAmPja8/6D0ZvSsJHALnvhVkD0MjhO5qG5ypi2rOwM/IxzJkPGlZMq8BiAup1vO892D0mAhAxQo9z8+31bAWRNLhEeZcbQS8V0=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1823.eurprd03.prod.outlook.com (10.166.42.149) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 17:57:10 +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; Wed, 13 Jul 2016 17:57:09 +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//81OAgAASrf6AAQoQAIAAh0QA
Date: Wed, 13 Jul 2016 17:57:09 +0000
Message-ID: <D3AC3F75.70B75%kenny.paterson@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> <60BA093E-2B35-4F88-B6E1-81113CC27AA8@rhul.ac.uk> <D3AB940F.27C59%qdang@nist.gov>
In-Reply-To: <D3AB940F.27C59%qdang@nist.gov>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.148.47]
x-ms-office365-filtering-correlation-id: 5aca3701-607c-449d-ce3d-08d3ab471c68
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1823; 6:b3Tu4rE1wdqB7AB4Kujq1uFfDz5JIDwOmNs8T47O5DmvjbzTHIiu3ZlkY/Bk+SJP9EntvGz3Fjtowy+ZsN8M+UZY6jDoJEkE5ln2Aw2YRLYA4cTSsITxfbcxoljUqaLJXad1FcPCV1/mL4K2gSpr0oDYPcWbgbBY1iU2s0Y95V3SwVeoYsQsJzZfCKlkRaPjGVxQdejwp1+6BC3gREiOhK2oDvbOKhLShB2JNBic5kO1MSyKu+85F0jrxFm1JvPd1PeWkTfNKrtCN6VMnUtzEpNVe/zHbrL3XhT8a80zIsg=; 5:OYmpZ0pJyLl37etmNLS3jlreOrGrlApqMt8/yzXKgyskHRstdMN/evG/yrw4VAhay8r3ydPd+lYh9Mz16iMqe67RxprYC2T04gtnYXmcnyP1YPbZAHkCcq93LjJJmEX+wk0HbYG4g5C95lC+FGGYqQ==; 24:M5blgaiNGL7VfkHGsCl/Hu8QJXpJ1WYzaDnEE+cNWIM5Yxt7q0Hbre6olGFVz85tSquOuVzdcNUmJQj13lb5pCrNJfWCxsFWMUFHKO8WdlI=; 7:6DMdzjgS1f3rmzE3cSY+uqv0u4cXmBFv/sE1EO/Do+NeY4zwBr+52dgA6HrfBssYBVJ6uV1KtvbhMP2OWjpep/Nn+5WA/eiYDICB0g7eZod1mz9FSRs14bK962F+I8GH0wbUOyD0LTv2Rl0piBkpl2ndOU0dbgQbS3xAcGH7jGJNcgMEyzpZMcsb+WKLk1KMbY2mCDFz5e1TJu0QlrivD7bOY+1Nh47WsvwEp9ermGmPgTAjv1aNMlbwazaS27sb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1823;
x-microsoft-antispam-prvs: <VI1PR03MB1823E23E3E56A45E86781BC7BC310@VI1PR03MB1823.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)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1823; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1823;
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(24454002)(199003)(189002)(81166006)(74482002)(77096005)(230783001)(36756003)(19580395003)(19580405001)(110136002)(87936001)(2900100001)(97736004)(2950100001)(3280700002)(3660700001)(5002640100001)(4001350100001)(83506001)(122556002)(92566002)(86362001)(81156014)(6116002)(3846002)(586003)(106356001)(106116001)(102836003)(8666005)(7736002)(68736007)(54356999)(76176999)(50986999)(101416001)(8936002)(66066001)(105586002)(4326007)(2906002)(10400500002)(305945005)(189998001)(7846002)(8676002)(93886004)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1823; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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="utf-8"
Content-ID: <5728ACE9F965B04CBD323330FE9D7065@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 17:57:09.6049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1823
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PZDDZM1DoBpSBjUbwmUKyVcwrM8>
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 18:04:45 -0000

Hi

On 13/07/2016 11:55, "Dang, Quynh (Fed)" <quynh.dang@nist.gov> wrote:

>Good morning Kenny,
>
>On 7/12/16, 3:03 PM, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote:
>
>>Hi,

<snip>

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

OK, then I think we're done here.

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

Again, look like we're done here.


>Your paper is a nice one which gives users good information about choices.

Thanks, I'm glad you found it useful.

Cheers

Kenny 

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