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

Andrey Jivsov <> Thu, 02 March 2017 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83CCC127601 for <>; Thu, 2 Mar 2017 15:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KKn7a3Bc75UI for <>; Thu, 2 Mar 2017 15:15:32 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08469127A90 for <>; Thu, 2 Mar 2017 15:15:31 -0800 (PST)
Received: from ([]) by with SMTP id jZwUc772Zq9PljZwYcwOpq; Thu, 02 Mar 2017 23:15:30 +0000
Received: from [IPv6:::1] ([]) by with SMTP id jZwXcMFBsBKYljZwXcdZdR; Thu, 02 Mar 2017 23:15:30 +0000
References: <> <> <> <> <> <>
From: Andrey Jivsov <>
Message-ID: <>
Date: Thu, 2 Mar 2017 15:15:28 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfBf7lS8Q0JEbAWXCA/HtzBX4ko3u6Qf3WoVF+wD0qO/OO7ObLu4M76RVC1o0+e6YW8KtbyAx5IHKn4rlkXoBLIkEz3iKUYmGU31G1ClFzxNs8wrpUdw6 13jFtXnJXtzwVMMceT6uWzV4jcZEq5xBiOle6GZ008GlMNrkE+C1y9oluNcwRSU/fnN+DPnPeObVEQ==
Archived-At: <>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
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: Thu, 02 Mar 2017 23:15:33 -0000

I also think that counting in blocks is cleaner. Counting in bytes is a
close alternative.

I have a few nits below:

On 03/02/2017 01:44 PM, Brian Smith wrote:
> Aaron Zauner <> wrote:
>> I'm not sure that text on key-usage limits in blocks in a spec
>> that fundamentally deals in records is less confusing, quite
>> the opposite (at least to me).
> 1. Consider an implementation that negotiates with another
> implementation to use a very large record size such as 1MB records. If
> the limit is specified in terms of records then the limit would need
> to be readjusted to the new max record size, or else the new extension
> is potentially unsafe to use. This shows that specifying the limits in
> terms of records is brittle.

Hm, while I agree that counting in wrong units is the main problem here,
we over-count with records, which means that we re-key faster than needed.

> 2. If it is only safe to use an AES-GCM key for a certain number of
> blocks, where in the code is the best place to enforce the limit on
> the number of blocks? IMO, it is better to enforce it in the AES-GCM
> implementation itself, underneath the TLS layer. In that case the
> limit is best expressed in terms of the number of blocks. Specifying
> the limit in terms of records would be optimizing for implementations
> that enforce the limit at the wrong layer of abstraction.

Given that the event of reaching the limit requires TLS-level action,
checking the limit at the TLS level seems reasonable. The lower-level
block-cipher code should still have the logic to error out (using a more
relaxed limit).

>> As I pointed out earlier: I strongly recommend that any changes
>> to the spec are as clear als possible to engineers
>> (non-crypto/math people) -- e.g. why the spec is suddenly
>> dealing in blocks instead of records et cetera. Again; I really
>> don't see any reason to change text here - to me all suggested
>> changes are even more confusing.
> Given a limit in blocks, the arithmetic to keep track of the number of
> blocks is trivial, and very similar to the arithmetic that's already
> needed to split up a large byte stream into records and keep track of
> the record sequence number.

Also please consider counting in bytes. This may be more natural,
especially with AES-GCM that doesn't expose higher levels to the block
size granularity (as much as CBC does, anyway).

> Cheers,
> Brian