Re: [TLS] Data volume limits

Dave Garrett <davemgarrett@gmail.com> Wed, 16 December 2015 04:19 UTC

Return-Path: <davemgarrett@gmail.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 64BD21A6FBC for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 20:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 CDJO3aysxcIC for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 20:19:16 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3134D1A6F82 for <tls@ietf.org>; Tue, 15 Dec 2015 20:19:16 -0800 (PST)
Received: by mail-qg0-x236.google.com with SMTP id 21so25516230qgx.1 for <tls@ietf.org>; Tue, 15 Dec 2015 20:19:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=TFqV+ltUlGPiZS07ExuwmmGD9ImS5KXz5uTyW/PQXtk=; b=oJ+eHGQvmndheamkqGzeQ6anMySiBnEQhkyBG5oOqImkPYuD+Q56JCzYg3r5O6Lrc3 8YHP7I6kAnP2akbMqV03eBYetAVqu2Pot3GKr3JhM2OEO2NCn0SVR7nNXnJOV3Eq1399 5v6DdCSNFqpnMkof0swPa1flx80mHRozJp5MNk2bMiNTXzsFMPUjHsfFMNuIJRXDm+6I HB7TtghDbdSammEEmychZz4Eyi9A0CTmHmFCGChxvN2/0RaFfzEjnnRdGsyGVYwraHVE FfZRBt+zICJRTtj1EtqanjnnBf8xO2Fi4DZ33SwcqUHfOiQDfhqURcJ4K2z1bUWrm6xp 5KeQ==
X-Received: by 10.140.18.199 with SMTP id 65mr56368216qgf.10.1450239555293; Tue, 15 Dec 2015 20:19:15 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id e10sm1931807qka.1.2015.12.15.20.19.14 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 15 Dec 2015 20:19:14 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 15 Dec 2015 23:19:13 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <201512152308.08667.davemgarrett@gmail.com> <CABkgnnX9zX2PSYY80AAdQ2Ftkrw3kSSX3JFz-yMUvp62Np7BSg@mail.gmail.com>
In-Reply-To: <CABkgnnX9zX2PSYY80AAdQ2Ftkrw3kSSX3JFz-yMUvp62Np7BSg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201512152319.13902.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_XwVNeH66Wmu5C7efxIt4xPnUdw>
Cc: "tls@ietf.org" <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, 16 Dec 2015 04:19:17 -0000

On Tuesday, December 15, 2015 11:11:36 pm Martin Thomson wrote:
> On 16 December 2015 at 15:08, Dave Garrett <davemgarrett@gmail.com> wrote:
> > We could just make the threshold a configurable parameter, with default/maximum at 2^32 bytes. Each endpoint could just provide its threshold in a new extension. Both get to specify what they want and it could be lowered arbitrarily for testing or panic fix.
> 
> That sounds more complex than the current option.

It's the difference between one signal in the handshake followed by predictable rekeying and an arbitrary number of signals at arbitrary points after the handshake.


Dave