IETF Logo Mail Archive

Re: [TLS] Data volume limits

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 28 December 2015 20:56 UTC

Return-Path: <ilariliusvaara@welho.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 BF3DC1ACC92 for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SWBZgBExpNNL for <tls@ietfa.amsl.com>; Mon, 28 Dec 2015 12:56:13 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A71ACC8F for <tls@ietf.org>; Mon, 28 Dec 2015 12:56:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7549821E; Mon, 28 Dec 2015 22:56:11 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id KgXenPIkFJrW; Mon, 28 Dec 2015 22:56:11 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D34C91EE; Mon, 28 Dec 2015 22:56:10 +0200 (EET)
Date: Mon, 28 Dec 2015 22:56:10 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Message-ID: <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20151228205101.17780804.92503.42669@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20151228205101.17780804.92503.42669@ll.mit.edu>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xhoV1fy2WtY-F8qxak9SFwdzw1M>
Cc: Florian Weimer <fweimer@redhat.com>, "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: Mon, 28 Dec 2015 20:56:14 -0000

On Mon, Dec 28, 2015 at 08:51:01PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> 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???

OTOH, you can't drop an attacker knowing older key without doing
new key exchange.

Introducing new randomness would complicate the rekeying _greatly_
as now you need to handle synchronization (which also causes nasty
problems at application layer). So one wouldn't want to do that
without really good reason.

Breaking the symmetry between rekeyings (including the rekey counter
in key derivation) might be feasible tho.


-Ilari

v2.23.0 | Report a Bug | By Email