Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <> Mon, 28 December 2015 21:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 63C461ACCFA for <>; Mon, 28 Dec 2015 13:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uQtc9wffjcoN for <>; Mon, 28 Dec 2015 13:17:08 -0800 (PST)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 75D951ACCF8 for <>; Mon, 28 Dec 2015 13:17:08 -0800 (PST)
Received: from ( by (unknown) with ESMTP id tBSLH5gP031587; Mon, 28 Dec 2015 16:17:05 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "Salz, Rich" <>, Eric Rescorla <>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AdFBtRnBde9nh48KlkmRxpLGJ4HFmw==
Date: Mon, 28 Dec 2015 21:17:04 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0794908206=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-28_13:2015-12-28,2015-12-28,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512280400
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: Mon, 28 Dec 2015 21:17:10 -0000

"Cranking the KDF" suffices for providing "subkeys" that are cryptographically intractable, which should address the concern of "too much plaintext under the same key". That's less than what I'd consider a "full re-key". ‎And even then "cranking the KDF" with something newly-random isn't a bad idea at all.

I don't think common crypto expertise would disagree.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Salz, Rich
Sent: Monday, December 28, 2015 16:09
To: Blumenthal, Uri - 0553 - MITLL; Eric Rescorla
Cc: Florian Weimer;
Subject: RE: [TLS] Data volume limits

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