Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

"Dang, Quynh (Fed)" <> Fri, 10 February 2017 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F44F12958B for <>; Fri, 10 Feb 2017 10:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ES1RvkwcxzhY for <>; Fri, 10 Feb 2017 10:47:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B312129A8E for <>; Fri, 10 Feb 2017 10:47:59 -0800 (PST)
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=SWlHQSGNzXrUwlpYkIj1FyMXLO0pcIvMaQf70BdFMmk=; b=do9qw8Iha7GPBa5Ou/X8/luBqD92nOn29KfDFkRqn+vJPFyzbVXzQd4bgjxcS2lp5zdPCqaEcBKhT8u4rNo3epQ2mVh0PBkKgpwcLIYaPh42D5h1SdCcL9MlhzUUuGcGng4VssEaU4P6tLH/ntJMdXIyNfIjs5zhXDekSFJh1Ws=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 18:47:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 18:47:57 +0000
From: "Dang, Quynh (Fed)" <>
To: Rene Struik <>, Sean Turner <>, "<>" <>
Thread-Topic: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
Thread-Index: AQHSg84y+88vw5exDE6fOqGEW6ep0A==
Date: Fri, 10 Feb 2017 18:47:57 +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: bb897306-0c91-4a53-d16e-08d451e554db
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1462;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:vjCOHdPXo2e/bEetYR/p871QNDIolpEpy6yRCuI8k+eFAXOfmAsennoSqAwWQP2S62VqElVPUCk+ZoNlwzYTlrZX40u9oinHZWqzIhqn6uujFk86kgqDHY78I6QFzO3EPARk43qfQtqKu3Y1pYh9xURBxN+U5k+1t4kMxm24wil1/mNQxv7P4dkiTBcjfduiTipu4jUdqyUgaHE1QsJNhCMcipQCmW8YR2v6aSa0LLlRVuQOQbyjG+T45yaddT56sSMdvKiN1zp/GONXxn1npnc7pa76JxOh7wvnkiztx3VVydqNxHGOrEo8MYdVZMw6XywpdepAScBBV45faGq+syOgki7s1llYvDfRpyC9QX/ke4BlW/Hd+ilG8UN47PehihcUlIFYyzjy6CziE/w4A8783ExEgXSH4peJJOhWFsw8mzo5cV0nmyVjVKih33eVjvR/AC5b6awhlpXYjzsnR2uDFjuPOQJvun1KJ+WaJivyXVfLWwhjWoDUEymbhruUED6g7PINt4rhQGyH9mUgrg==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(199003)(189002)(377454003)(24454002)(2900100001)(2906002)(8936002)(3280700002)(3846002)(81156014)(2950100002)(102836003)(4326007)(6116002)(53936002)(5660300001)(81166006)(8676002)(38730400002)(105586002)(92566002)(106116001)(6246003)(189998001)(53546003)(106356001)(66066001)(76176999)(4001350100001)(54356999)(3660700001)(50986999)(6486002)(97736004)(77096006)(6436002)(325944008)(39060400001)(6506006)(229853002)(6306002)(101416001)(6512007)(99286003)(54896002)(236005)(25786008)(606005)(86362001)(68736007)(7906003)(36756003)(122556002)(575784001)(83506001)(7736002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462;; 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: multipart/alternative; boundary="_000_D4C3749F2F856qdangnistgov_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 18:47:57.6983 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
Archived-At: <>
Subject: Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 18:48:02 -0000

Hi Rene,

From: TLS <<>> on behalf of Rene Struik <<>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <<>>, "<<>>" <<>>
Cc: IRTF CFRG <<>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS]<> provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update Section 4.6.3<> prior to reaching these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, which - in some implementations - have been shown to be successful at recovering keying material with a relatively small number of messages encrypted using the same key. While results are highly implementation-specific, thereby making it hard to provide precise guidance, prudence suggests that implementations should not reuse keys ad infinitum. Implementations SHALL therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work for AES-GCM only in TLS 1.3 ?

See also my email of August 29, 2016:

On 2/10/2017 12:07 AM, Sean Turner wrote:


We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).


Cfrg mailing list<>

email:<> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363