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

"Dang, Quynh (Fed)" <> Tue, 12 July 2016 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3983312D59F for <>; Tue, 12 Jul 2016 10:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MQxbhWSyXH1d for <>; Tue, 12 Jul 2016 10:56:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3517312D5B0 for <>; Tue, 12 Jul 2016 10:56:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( by ( with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 17:56:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 17:56:17 +0000
From: "Dang, Quynh (Fed)" <>
To: "Paterson, Kenny" <>, "Dang, Quynh (Fed)" <>, Eric Rescorla <>, "" <>
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: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: <>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2016 17:56:21 -0000

Hi Kenny, 

On 7/12/16, 1:39 PM, "Paterson, Kenny" <> wrote:

>On 12/07/2016 18:12, "Dang, Quynh (Fed)" <> wrote:
>>Hi Kenny, 
>>On 7/12/16, 1:05 PM, "Paterson, Kenny" <> wrote:
>>>On 12/07/2016 16:12, "Dang, Quynh (Fed)" <> wrote:
>>>>Hi Kenny,
>>>>I support the strongest indistinguishability notion mentioned in (*)
>>>>above, but in my opinion we should provide good description to the
>>>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
>>>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
>>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?