Re: [TLS] Data volume limits

Florian Weimer <> Mon, 04 January 2016 12:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4C071A874D for <>; Mon, 4 Jan 2016 04:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eyS4XicQb5SO for <>; Mon, 4 Jan 2016 04:13:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82B901A8711 for <>; Mon, 4 Jan 2016 04:13:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 10941C00330F; Mon, 4 Jan 2016 12:13:51 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u04CDmmu020051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 07:13:50 -0500
To: "Salz, Rich" <>, "Blumenthal, Uri - 0553 - MITLL" <>, Eric Rescorla <>
References: <> <>
From: Florian Weimer <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 4 Jan 2016 13:13:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Cc: "" <>
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: Mon, 04 Jan 2016 12:13:52 -0000

On 12/28/2015 10:09 PM, Salz, Rich wrote:
>> When the key is changed, the change procedure should involve new randomness. 
> I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not a cryptographer, maybe one of the ones on this list can chime in.
> "Crank the KDF" suffices.

The attacks against GCM are at the stage where even “periodically
increment the key by one“ would thwart them, right?

The risk is that without real re-key (introducing additional
randomness), someone might come up with a better attack that reduces the
security level below the design target, and which requires similar
effort as the existing GCM attack (four years of traffic at terabit
speed, it seems).

Real re-key is difficult to introduce as an afterthought (see my recent
response to Hubert), and I'd rather see such issues fixed at the cipher
level if at all possible.  The current update-key mechanism doesn't have
the complexity issue of real re-key, but it's ambiguous if it's a design
goal to paper over cipher deficiencies in the rest of the protocol.