Re: [TLS] Data volume limits

"Blumenthal, Uri - 0553 - MITLL" <> Wed, 16 December 2015 18:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35E5C1A8732 for <>; Wed, 16 Dec 2015 10:14:16 -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, MIME_QP_LONG_LINE=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 Mt2zfBg7_luS for <>; Wed, 16 Dec 2015 10:14:13 -0800 (PST)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 56A711A8725 for <>; Wed, 16 Dec 2015 10:14:12 -0800 (PST)
Received: from ( by (unknown) with ESMTP id tBGIDv8I006955; Wed, 16 Dec 2015 13:14:04 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Watson Ladd <>
Thread-Topic: [TLS] Data volume limits
Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuAgABzTID//8JOAIAAVduA//+8KgA=
Date: Wed, 16 Dec 2015 18:14:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3533116434_47352718"
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-16_07:2015-12-16,2015-12-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1512160300
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: Wed, 16 Dec 2015 18:14:16 -0000

On 12/16/15, 12:16 , "Watson Ladd" <> wrote:

>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL
><> wrote:
>> On 12/16/15, 10:50, "Watson Ladd" <> wrote:
>>>>If there are practical consequences, like loss of confidentiality – I’m
>>>> dying to hear the outline of a practical attack.
>>>The problem is that people design systems assuming something like
>>>indistinguishability. And so when you violate that assumption, all
>>>bets are off.
>> I don’t buy this. AFAIK, TLS has not been designed based on that
>> assumption. And I’m not making any bets. :)
>What security properties does TLS provide?

When the vast majority of TLS users employ it (TLS), they expect (a) that
TLS would ensure the authenticity of their remote peer, (b) that TLS would
protect their data exchange from being eavesdropped on and/or modified,
and (c) that these hold even when the “enemy” (whoever he might be)
controls the entire communications path between them and their peers.

You can translate the above into more formal definition. :-)

>In the past TLS users have made assumptions that TLS provides security
>properties it does not.

Very true.

>The solution to this problem is to provide the security properties
>that people expect, and they expect IND.

Not necessarily so.

As far as I’m concerned, IND-* is a good property to have, but not a
“sacred cow”. 

>>>What is the actual problem with either implementing rekeying, or
>>>limiting data to something like 128 GByte per connection?
>> As far as I’m concerned - none (no problem). And if there’s a way to
>> enforce rekeying sooner than that (limiting data-under-one-key to a MUCH
>> smaller amount) - I’d be in favor of that too. I just don’t accept the
>> above justification for it - and want to be shown how loss of IND
>> in TLS context leads to a practical attack.
>The practical attack is the loss of IND property. That's the attack.

And how does it translate into a loss of one or more of the above
properties? That’s what people want to hear. If you tell them that an
observer would be able to mathematically distinguish between truly random
data and their encrypted TLS stream (but only after 2^n blocks passed by,
and that’s their risk and exposure) - they’re likely to laugh you out of
the room.

>This is not a weakness in the proven bounds, but a mode limitation.
>Since you've agreed we can rekey more frequently

Yes I agree that we can, and probably should. Probably regardless of the
mode used, to keep things simple(r).