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

Rene Struik <> Fri, 10 February 2017 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3A441299D0 for <>; Fri, 10 Feb 2017 07:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e-R_N8fvfeDJ for <>; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A59B91299EB for <>; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
Received: by with SMTP id v96so53510408ioi.0 for <>; Fri, 10 Feb 2017 07:51:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=XPcXuB1iZWatzlaMyfATf2inUYKE9S/QLvLWARGRuDfvY5flgKlz2+OgLqXbqZSniZ z9ID57H8e5dYi8LWxlLA6rIqsXf7a8zGJIxrxePN31i7hxiRrN9mounL2IS6Atlg4i4y iAa+J+ACOqvOIdK+gZgWvGgADJLLhUMbyCvp/XUcd/gDn9xp9PqtOiiCxY27buffT1Aj pbSbj1w5PDVJx074WVssWmPuGXBLC6ocAnx7YBIdN+eMoIXwik3nSn4FHKgF+AVSCKA0 r7+3Pxmv+k0TUvk4j64x9QguWSPY7K4/3zASuGpnHLS8XlNCcgjOf3Yey44a+cRGRv6d P3Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=y4aQbk4tvRIWe00fHBCRnkJ0HlLhsiKKAlMnvRRl63Y=; b=EGMu4+9ga8XRkQUQNcE8h3c1j7DL26aB/ocyd73sF/F5dEKYPeVUjU2d5Fg77YiEuV od+x8NcukiodfnPvh6DMiVGRb9q+MoZE9OqBvTUaMsjbueVT8KzHSim9E5EnKWNWId9P zLhfU3sug537Mf0zHJnim6SxJtRd/obBFV8ctlTgMvoNWpGqAf+9IAdTlpRzgE+LyRk5 3Ls5W42dxUbduCkA6b4UA5t5EJ84AZfEAcwWIEeeXgDCSBsRHRUDqfmzZ433S3foHytE 9QaWqnHHhUfQHquepBBfUW7PU05EJQuOVFE8btUX/5UJnNMUF1VT6CGu/dhK4afHqmax FfKw==
X-Gm-Message-State: AMke39nWXu6QkoPeHYpKEt2MiPb4PazDjWN5hLCYdCorLskp+EEIUWzH5u7rRKfV5OzxvA==
X-Received: by with SMTP id 13mr9054953iou.0.1486741904935; Fri, 10 Feb 2017 07:51:44 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h15sm508251ita.20.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 07:51:44 -0800 (PST)
To: Sean Turner <>, "<>" <>
References: <>
From: Rene Struik <>
Message-ID: <>
Date: Fri, 10 Feb 2017 10:51:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6F183E4431F40EF448049DCE"
Archived-At: <>
Subject: Re: [Cfrg] 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 15:51:49 -0000

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 
updateSection 4.6.3 
<>prior to reaching these 

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

See also my email of August 29, 2016:

On 2/10/2017 12:07 AM, Sean Turner wrote:
> All,
> 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).
> J&S
> [0]
> [1]
> [2]
> _______________________________________________
> Cfrg mailing list

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