Re: [TLS] Data volume limits

Dave Garrett <> Tue, 29 December 2015 22:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6F2A1A8A59 for <>; Tue, 29 Dec 2015 14:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9mNIfZsyrwiG for <>; Tue, 29 Dec 2015 14:08:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C24E1A8A11 for <>; Tue, 29 Dec 2015 14:08:49 -0800 (PST)
Received: by with SMTP id 6so95541928qgy.1 for <>; Tue, 29 Dec 2015 14:08:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=C3Y046vmu85X5H4ZYHuL79c72uO7JteL4hNJYARKB/4=; b=tMKrkRRKE80b3G2MqC4Nhvp4dULGJ760bsq+OW9EkwC6l+0pu9+4bqRfVj3bwyPLtr tK7WEuatP8S0UTCIgaBWl1vvnC/BiX0AHxXhhp+8SqrPMTUV+SoLnVhL+KcWR3KnKVbT C22qMJreF0h5T5EOsArIdwoD+EPYsegOFGo0gsaaPu1jFjhysYtf/MNqEp7q8hZNunXx BSjrA6gFeu4njVpOEW6sqVlviw0EZfxagYVghD4XlMmaTFpQNzolHd28G1am5QYJYodF Twxe4XLxICnWG/CaaJhGBqeXU5x+ziB4duTPdTIyOBJ41ddwuFpfKa4i9ttncPbX20Px CY/g==
X-Received: by with SMTP id a32mr80449518qge.92.1451426928702; Tue, 29 Dec 2015 14:08:48 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id m107sm29909450qgm.19.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 29 Dec 2015 14:08:48 -0800 (PST)
From: Dave Garrett <>
Date: Tue, 29 Dec 2015 17:08:46 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Archived-At: <>
Cc: Florian Weimer <>
Subject: Re: [TLS] Data volume limits
X-Mailman-Version: 2.1.15
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: Tue, 29 Dec 2015 22:08:52 -0000

On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote:
> Note that NIST Special Publication 800-133 [1] defines these separate
> terms, and I suggest we use them in this conversation to avoid confusion:
> Key update: A procedure in which a new cryptographic key is computed as a
> function of the (old) cryptographic key that it will replace.
> Rekey: A procedure in which a new cryptographic key is generated in a
> manner that is independent of the (old) cryptographic key that it will
> replace.
> [1]

The current spec mostly uses the former, so yes, I guess we really should stop saying "rekey" if this has been defined like this. The single use of "rekey" in the doc should probably be changed to "key update" if we keep things as-is, then.

On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote:
> Note: the keys here are *not* derived from the old keys. Rather, they are derived via
> a KDF from the same secret that was used to generate the old keys.

Yes, but they are derived from the same entropy as the old keys. Yes, that's not the same thing, but they're not totally independent new keys either. If we're only doing this as a hack to fix ciphers that have problems (that really should just be fixed instead), then this is fine. I think it's just the fact that we _could_ add a full rekey mechanism without a fantastic amount of additional effort is what's giving some people pause.

If what we're really talking about is AES-GCM's data volume limits, what would be the best fix that just deals with precisely its issue, rather than doing a key update?

> Hmm... It seems to me that there are three (at least) three separate
> possible designs:
> 1. Generate the new keys by a new application of the KDF with no additional inputs.
> 2. Generate the new keys by a new application of the KDF with additional random inputs.
> 3. Generate the new keys by a new PK key exchange (potentially also using the old
>     keys and new random inputs).
> These all have different security properties and it's not clear to me which buckets
> these fall into.
> As far as complexity goes, 3 is more complicated than 2 which is more
> complicated than 1.

From a certain perspective, doing a full new (EC)DHE with new randoms for a full rekey is less of a change to the spec than a simple key update or something in between. It is somewhat akin to a stripped-down version of renegotiation to just renegotiate the ephemeral key, but not any of the other parameters. I think it's worth considering, but I don't know if we absolutely need something here at all.