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

Brian Smith <> Thu, 02 March 2017 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BB1F129670 for <>; Thu, 2 Mar 2017 13:44:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FoAt1ak46nMp for <>; Thu, 2 Mar 2017 13:44:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E002B1295EF for <>; Thu, 2 Mar 2017 13:44:13 -0800 (PST)
Received: by with SMTP id 203so2016462ith.0 for <>; Thu, 02 Mar 2017 13:44:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PmXHXrUwBBn3FKB1UU9gitiSHibI8xN3gm54gcAYriU=; b=nVw1c2CYUAg2mngp1P/32NRJLF60WVhHh9snq/T6MNTSUENcNmMs3+n36J0Gm4dieL WXAa8EFoaHcqfV5FVHGuVPjlrTIC3da9ED58GUDkIWVi1Zo9JJkPhdP77vDbbEarXkSi T5cFmzyTAHG/X+NeMUVTFhqYXOsvYxC2js5PpW/Hzailv+rVbXc/4dbyFzE7rkhDHjWI 2LXyyhfN2i6/G0TJtrIWq3SLsuL4KjPwpxK7HedbkrFG8HyIOC793+a067NeRSBHOJ7d A+5SyLNPlZTnViNplQ4rWdEIq2xg1a55n8DXA/ghM3za1Js8M/rHUwkigAx3zVa7ZE2v 4asQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PmXHXrUwBBn3FKB1UU9gitiSHibI8xN3gm54gcAYriU=; b=FMjTFToB2A0XQDi4GFTDnSO6stAnJoVJQVtZJmatPeuW9UCLBtRbU0Iy8HA0nwHWsu WzFY9Gy/xcsfWnxanpGSosA5W933zRpH7cykFM19A6DoxU+2/RXRP+KJ5iRBSQ3WgZ8V DmkFuSWlTijvnS/Ii0DcOrrqyznXcXQBEUNLRrjE9yDfxhq2NT3F5Z1/XWZ+il7OtuJz Q8mgDtszs9pfmJ6XdrsbPKWvyEHkZq+ULeYg91Fm3YFzJtKRFv4z8Az4bolRxOIGaP/E BaDmkUoN8oOjgOF5X5Ss0UTUoOGlo71eC/58jHNZK101CuuqzvTKdSSokk5qGdcUa0jk Jgaw==
X-Gm-Message-State: AMke39k7ark8PGsQxIr4HA9X2xFAhjQuGdxEY4b/iguRq7CIi+67R5vCYHwBjq0D+RDjP45I4qQIK92UEfBLIQ==
X-Received: by with SMTP id m202mr493249ita.58.1488491053194; Thu, 02 Mar 2017 13:44:13 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Mar 2017 13:44:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Brian Smith <>
Date: Thu, 2 Mar 2017 11:44:12 -1000
Message-ID: <>
To: Aaron Zauner <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IRTF CFRG <>, "<>" <>
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 21:44:15 -0000

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.

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.

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