Re: [TLS] Data volume limits

Benjamin Kaduk <bkaduk@akamai.com> Wed, 06 January 2016 00:56 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796E1A0AF1 for <tls@ietfa.amsl.com>; Tue, 5 Jan 2016 16:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZwokcFwXeJQ for <tls@ietfa.amsl.com>; Tue, 5 Jan 2016 16:56:05 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 291651A03A2 for <tls@ietf.org>; Tue, 5 Jan 2016 16:56:05 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C6A45423714; Wed, 6 Jan 2016 00:56:03 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id B08F442372D; Wed, 6 Jan 2016 00:56:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1452041763; bh=2qQkKcKsMaEmgEOLOP+5grW1nauzekwq1LBdBcxRhqE=; l=1088; h=To:References:Cc:From:Date:In-Reply-To:From; b=Iq5jno9Ax6RRStJ1mJ78JFFVwfIFXLawJhMbbk034w1RkdIIjTKSgcflGmrQXE9f3 CLWZVguTrsOwiM9MvRYERJRiJnUaoG7cRJv/42T2HhK8hJEC/8S1y2mSiDsO0Zz0Oj sFvBjj8ZcOZ3PUAtKDjG7NltiERZILyrkJ4aGSxk=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7D1542029; Wed, 6 Jan 2016 00:56:03 +0000 (GMT)
To: Florian Weimer <fweimer@redhat.com>
References: <r422Ps-10112i-A7598D6B042F444AA21AABEA3552ADF5@Williams-MacBook-Pro.local> <3389370.HsjF9M0k0s@pintsize.usersys.redhat.com> <568A5F71.9040002@redhat.com> <1681538.bGQ4XbsTo4@pintsize.usersys.redhat.com> <568A63F7.10307@redhat.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <568C6623.4020904@akamai.com>
Date: Tue, 05 Jan 2016 18:56:03 -0600
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: <568A63F7.10307@redhat.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BQgMnTjoMe2aSYGTbhP3FePORP0>
Cc: tls@ietf.org
Subject: Re: [TLS] Data volume limits
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2016 00:56:06 -0000

On 01/04/2016 06:22 AM, Florian Weimer wrote:
> On 01/04/2016 01:19 PM, Hubert Kario wrote:
>
>>> Dealing with this during the initial handshake is fine.  But
>>> supporting direction-switching after that is *really* difficult.
>> yes, this is a bit more problematic, especially for one-sided transfers. 
>> For example, when one side is just sending a multi-gigabyte transfer as 
>> a reply to a single command - there may be megabytes transferred before 
>> the other side reads our request for rekey and then our "CCS" message
> Yes, this is the issue I meant.  I simply don't see a way to re-inject
> new randomness without a round-trip.  (Key update without new randomness
> doesn't face this challenge, but then it's mostly cheating.)
>

EKR asked for an explanation of what risk you want to mitigate by adding
new randomness on the 28th of December, but I don't recall seeing an
explanation.  This belief that key update without new randomness is
undesirable does not really seem to be supported by any concrete
arguments, in the recent history of this thread.

-Ben