Re: [TLS] Data volume limits
Watson Ladd <watsonbladd@gmail.com> Sat, 02 January 2016 01:20 UTC
Return-Path: <watsonbladd@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 532631B29D2 for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 17:20:45 -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 kBes0Vo41QFF for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 17:20:44 -0800 (PST)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 DC0871B29D3 for <tls@ietf.org>; Fri, 1 Jan 2016 17:20:43 -0800 (PST)
Received: by mail-yk0-x229.google.com with SMTP id v14so112080820ykd.3 for <tls@ietf.org>; Fri, 01 Jan 2016 17:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Em7TltCAD+dpX9a5xERISZ7/Os1ebr/B3fMDPAEmw8=; b=BYfa0JLHYiJCw9qTFB4RsMguVYJhIxjMFOFWnam0EA5TUjQjN9GwpL092YEWQ+c7yB N43osTF2zV9DChAlPheNRZiBGdTe2AitfFJHfnRkiAW/1B5Z/8e0YJi9GVaRHtqdA0ZG yrwALUiUZgOp5oP//21/iZMSFoodFvfkBXl9ijQQ+GpSutYNVmq7/MCXoAVdAp0/lEYO wU/KsdLiBqmaqYis92CJWAWBPbpADZ+C6bO24dAYoQClWuy4bUHELlfRcwKvE45QMMMR a/y+DAr7ONWoV595Jwj3PhN/E4oVWkNYVNQaeZ86hSVy3OdElsjRKbtCPiVKxKiwKaWf 9LdQ==
MIME-Version: 1.0
X-Received: by 10.129.29.14 with SMTP id d14mr50186992ywd.182.1451697643141; Fri, 01 Jan 2016 17:20:43 -0800 (PST)
Received: by 10.13.216.150 with HTTP; Fri, 1 Jan 2016 17:20:42 -0800 (PST)
In-Reply-To: <CAFewVt4rTNqXwOFp7PhvNTdiG7SdyjW1_wATdXOeQv7-uRcdTQ@mail.gmail.com>
References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> <CAFewVt4rTNqXwOFp7PhvNTdiG7SdyjW1_wATdXOeQv7-uRcdTQ@mail.gmail.com>
Date: Fri, 01 Jan 2016 20:20:42 -0500
Message-ID: <CACsn0cmFT+uiyxnyzGeP8qQs+4k=jMSPbO0zagsRy5A_xdHBYA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/iO2PssIdplJy3IswDlg8KtXV66I>
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: Sat, 02 Jan 2016 01:20:45 -0000
On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith <brian@briansmith.org> wrote: > Ilari Liusvaara <ilariliusvaara@welho.com> wrote: >> >> OTOH, you can't drop an attacker knowing older key without doing >> new key exchange. > > > I think it would be very unfortunate to have the complexity of key update > (the new keys are derived from the old keys) without having the benefits of > rekeying (the new keys are independent of the old keys). What complexity? Sending a special packet with a different protocol that triggers a change in record layer state is not that tricky, and even DTLS is designed to handle this already. In fact one could even use the epoch number implicitly. What benefits? The concern isn't that an attacker obtains the key, but that confidentiality is lost. If we're worried about attackers who can read memory the answer is clear: write in a language that doesn't permit this. > > Note that NIST Special Publication 800-133 [1] defines these separate terms, > and I suggest we use them in this conversation to avoid confusion: > > Key update: A procedure in which a new cryptographic key is computed as a > function of the (old) cryptographic key that it will replace. > > Rekey: A procedure in which a new cryptographic key is generated in a manner > that is independent of the (old) cryptographic key that it will replace. > > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf. > > Cheers, > Brian > -- > https://briansmith.org/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau.
- Re: [TLS] Data volume limits Watson Ladd
- [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Benjamin Beurdouche
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Russ Housley
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Hanno Böck
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Andrey Jivsov
- Re: [TLS] Data volume limits Scott Fluhrer (sfluhrer)
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Stephen Farrell
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Bill Frantz
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Martin Thomson
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Andrey Jivsov
- Re: [TLS] Data volume limits Ryan Carboni
- Re: [TLS] Data volume limits Paterson, Kenny
- Re: [TLS] Data volume limits Simon Josefsson
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Henrick Hellström
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Nikos Mavrogiannopoulos
- Re: [TLS] Data volume limits Yoav Nir
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Salz, Rich
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Dang, Quynh
- Re: [TLS] Data volume limits Brian Smith
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Dave Garrett
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Samuel Neves
- Re: [TLS] Data volume limits Henrick Wibell Hellström
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits sneves
- Re: [TLS] Data volume limits Aaron Zauner
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Samuel Neves
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits Ilari Liusvaara
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Watson Ladd
- Re: [TLS] Data volume limits Eric Rescorla
- Re: [TLS] Data volume limits James Cloos
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Hubert Kario
- Re: [TLS] Data volume limits Florian Weimer
- Re: [TLS] Data volume limits Benjamin Kaduk
- Re: [TLS] Data volume limits Florian Weimer