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

Andrey Jivsov <> Sat, 11 February 2017 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FB5B1294A6 for <>; Sat, 11 Feb 2017 14:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1matrBJn5W4j for <>; Sat, 11 Feb 2017 14:26:34 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2F711294A9 for <>; Sat, 11 Feb 2017 14:26:34 -0800 (PST)
Received: from ([]) by with SMTP id cg7ZcTMT9xUJacg7mchfFL; Sat, 11 Feb 2017 22:26:34 +0000
Received: from [] ([]) by with SMTP id cg7kc7T1TZHQdcg7lcPdGg; Sat, 11 Feb 2017 22:26:34 +0000
References: <>
From: Andrey Jivsov <>
Message-ID: <>
Date: Sat, 11 Feb 2017 14:26:31 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfIrRNC2ECcq9hyxNxpRErWYylz0YiQYH9a9NSF+YkoXk5owrBNT6x9/uWoWdP+TXPMcUtavSt/qv0fwx7MKBkVKdsCPgfkbIwCpFRi8HxthmDL0olN1B SDBjWjavyWYClFwuaO0FijFpZ1PP2oeEgNxVERN5Rs6TxDDEFvVLIk2i
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: Sat, 11 Feb 2017 22:26:37 -0000

On 02/09/2017 09:07 PM, 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]

I am an author of [2].

I originally thought that [0] could be improved, but [1], as seems to be 
a consensus, made the text even less clear, which motivated me to 

I see 2 main issues with [0]:

1. Counting in records. Worse, it counts in maximum-size records.

The original problem is measured in cipherblocks (16 bytes in TLS 1.3). 
Advanced products have the max TLS record size configurable. TLS stacks 
should not be expected to buffer the data to fill up the record, 
therefore, they are also sending many shorter records.

How should an implementer read [0]? If an implementation sends or 
receives shorter records, it has to re-key sooner.

Counting in bytes or cipher blocks is better. Implementers wishing to 
count in records can translate bytes into records easier that perform 
the reverse with [0] (however, I don't understand how counting in 
records can work correctly).

2. The numbers in [0] are not explained.

Given that I don't know the "components" of the formula, I am not 
exactly sure how to make adjustments for the #1.

The text in [0] should be clarified to show "components", e.g. what 
success probability was used.

( I recall that when [0] was worked on, there were discussions about 
multi-session issues. Was this a consideration? )

Finally, [1] assumed P=1/2^32 as a consensus-building choice. NIST uses 
this value to state limits on AES-GCM IVs 
( sec 8, 
sec A.5)

I would be happy with a lower value of P.

I think, however, that a comparison with the 3DES can be helpful. The 
recent SWEET32 attack on 3DES works with the practical P=1/2. Using 
P=1/2^32 for 3DES implies rekeying after 0.5Mbytes of traffic. I suspect 
that these who implemented data limits for 3DES rekey less often than on 
each 0.5Mb.