Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <> Mon, 28 December 2015 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A2701ACC86 for <>; Mon, 28 Dec 2015 12:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 LQ2_3dpwfNUF for <>; Mon, 28 Dec 2015 12:51:03 -0800 (PST)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 36B4F1ACC82 for <>; Mon, 28 Dec 2015 12:51:02 -0800 (PST)
Received: from ( by (unknown) with ESMTP id tBSKp2Mo025017; Mon, 28 Dec 2015 15:51:02 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Eric Rescorla <>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AdFBsXYBde9nh48KlkmRxpLGJ4HFmw==
Date: Mon, 28 Dec 2015 20:51:01 +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="===============1557926193=="
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-1512280390
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 20:51:05 -0000

When too much plaintext has been encrypted with the same key, the key needs to be changed. When the key is changed, the change procedure should involve new randomness. 

What's the confusion here???

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

To be clear, the concern that we are trying to alleviate is encrypting too much plaintext with the
same key (see the discussion by Watson at the beginning of this thread). For that purpose,
I'm not following why we need to introduce new randomness (draft-11 doesn't do so,
but just cranks the KDF forward).

It's possible I've misunderstood something, though, so happy to be corrected.


On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL <> wrote:
Off-hand, key update or re-key without new/fresh‎ randomness sounds weird.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Eric Rescorla
Sent: Monday, December 28, 2015 15:37
To: Florian Weimer
Subject: Re: [TLS] Data volume limits

On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer <> wrote:
On 12/28/2015 09:11 PM, Eric Rescorla wrote:

>> You still have the added complexity that during rekey, you need to
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
> That's not intended. Indeed, you need to be able to handle the old key
> in order to send/receive the KeyUpdate. Can you elaborate on your concern?

Ah, so you want to keep the current mechanism and not inject fresh
randomness?  Isn't this fairly risky?

Can you explain the risk you are concerned about in more detail?