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

"Paterson, Kenny" <> Tue, 12 July 2016 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53BC212D59B for <>; Tue, 12 Jul 2016 10:39:22 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 uCLR_84AbrtH for <>; Tue, 12 Jul 2016 10:39:20 -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 F327412D586 for <>; Tue, 12 Jul 2016 10:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N8FAaIR8kNMPWTtyeacemA9SzPvw8eASw3+PqH3Z5V4=; b=Nff268W/ALOXREyiJ5u0mYrufjcaLsfFkmY/d511VkeD9s5crDpdzobedxWB8k8pQxn0MHVuVmp8HG1fUTfRrFRzZ/GQjSVeHVGpnpaWYatDXv9ufmHWbhaRvt+RqHe2tycS3Yg9Grtw9vEReb3rwviQGjz8MltVniXszpw5tXk=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 17:39:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0539.019; Tue, 12 Jul 2016 17:39:17 +0000
From: "Paterson, Kenny" <>
To: "Dang, Quynh (Fed)" <>, Eric Rescorla <>, "" <>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26esSHCH//KpSE6diooP42E52KAUxHSAgAAiIQCAAAGugIAAMOeA///wrQCAABjmgA==
Date: Tue, 12 Jul 2016 17:39:16 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, 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: 6ab184cb-f561-4316-3c3e-08d3aa7b72aa
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:UKT3e+7hIkrocngBg+0C9fIVxoMJQilWOkgs2sAt2NcfVyaS3JVQ4G1QnwVlfiQcai35vSgg6sCeuNT9+TCijH2sg9HAyUd5aVJOZDMxm6GNX6L+m4eLk307qstPbjjnwDwI0tpoxzXhiM8QiXEoda5bZQOmPJvID/gC19r8LxftkGvJxEGxSckjWMm3bma7pvA13zB0AwwxG4rEshtTvcP9qDNMgjMVv4HDo0Gg5Z9NaiYO+bgMxZTcA/BX/6izljvFKX0wmUteDVJHX7CaxnH0aly2jAL6nffu7+w0VV4=; 5:a0QJ53EtJHF3SaDEOHHD1FkVuy9elb6pqIo0cvUBo6eiBaVHPTsQhWM0cUMGhJZxdCnvnNIcD2Vn37uvdMPhdnnI9a8yZyZiC+disXSQVt3FnZ8uK+gXM8qFjv8Km/5hV73GkKnBWqLcyuokXcbKTg==; 24:IgJ7RtZlIWC5SY2qtir0MpA9EyjReXVSc4mgbVJJOhTGzudlq4NwQohEiF21HvHB3pgMVlQ8l7RhpYIw4Wjkc0OHVXHpkbXgRLhMLIAskqg=; 7:zgOEfAdZiQDXlCNedW24d3QCOvpvPwLGpPFVUwL/H4cZXL1I+sdYk/7agklWaDsZTHVYpnjDHUjY7y/lbXaECtHmKCuLWIltXSPRaokfbB0iZyWsbc9i+mq94ooiTl0YxTWW6BZ6v7K01MBJtZA70jW3JYYO2S862fQjmSeGTpvNqv091WGkxp52AQzuOWG+rt9l/YwKiXeueBM9VwitNRyT3OG49LeQt4xXnJl7F1sS4NfJga7QXxyQYY2E1XJs
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822;
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); 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)(101416001)(305945005)(66066001)(36756003)(81166006)(2950100001)(2900100001)(54356999)(76176999)(50986999)(8666005)(7736002)(74482002)(8936002)(2501003)(83506001)(7846002)(122556002)(92566002)(81156014)(77096005)(19580395003)(19580405001)(3846002)(230783001)(106116001)(2906002)(6116002)(68736007)(106356001)(102836003)(87936001)(105586002)(86362001)(3280700002)(107886002)(10400500002)(3660700001)(5001770100001)(97736004)(11100500001)(189998001)(4001350100001)(93886004)(8676002)(5002640100001)(586003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 17:39:16.9249 (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: <>
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:39:22 -0000


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