Re: [TLS] Data volume limits
Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 01 January 2016 14:40 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 29B681ACD1C for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 06:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.09
X-Spam-Level: *
X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 GyJJ37QYPnRU for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 06:40:21 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E71581ACD19 for <tls@ietf.org>; Fri, 1 Jan 2016 06:40:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EE6CD1FC; Fri, 1 Jan 2016 16:40:18 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id EO_GbvYCBpij; Fri, 1 Jan 2016 16:40:18 +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 7530E27B; Fri, 1 Jan 2016 16:40:18 +0200 (EET)
Date: Fri, 01 Jan 2016 16:40:16 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Henrick Wibell Hellström <henrick@streamsec.se>
Message-ID: <20160101144016.GA25598@LK-Perkele-V2.elisa-laajakaista.fi>
References: <r422Ps-10112i-A7598D6B042F444AA21AABEA3552ADF5@Williams-MacBook-Pro.local> <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <CABcZeBP4NJDAp_jJgQ0R4-zRgNYBYno4GWkwnJz61fO7T1YX2w@mail.gmail.com> <568676E8.6090802@streamsec.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <568676E8.6090802@streamsec.se>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZadgdmVO1SqdjBeWnpypNAfodCY>
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: Fri, 01 Jan 2016 14:40:23 -0000
On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote: > I think it is a good idea to rekey AES-GCM after approximately 2^32 records, > give or take a few magnitudes. > > The question for me isn't whether AES-GCM requires frequent rekeying (it > does), but exactly how much complexity the rekeying mechanism would add, to > the protocol and to implementations. There have been three basic proposed categories of key update schemes: 1) Ratchet keys through KDF, no new randomness. 2) Ratchet keys through KDF, with new randomness 3) Do new PK key exchange Also, if one doesn't want applications to have to be aware of rekeying, one can't introduce new flights ("fully asynchronous key update"). This would cause _severe_ constraints. Then there is strictly weaker constraint that one can't introduce "dead air", where the protocol can't make forward progress without waiting for response (the previous constraint is sufficient but not necressary to meet this). Firstly, 1) The current scheme is example of 1) without new flights. Basically, send a message to ratchet sender's keys. There is no symmetry-breaking between updates, so if k(i) = k(j), then k(i+n) = k(j + n) (such symmetry-breaking could be introduced by adding key number to KDF inputs). Also, I noted that the current scheme seems to break HKDF pairing: It tries to expand already expanded value (traffic secret). This violates pairing. Also, scheme like this could nicely work with DTLS: One could use epoch numbers to signal rekeying (but one would then take care not wrap epoch in way that could cause confusion). Then 2) Doing 2) without new flights would imply: - Two traffic keys, one for each direction. The low-level ciper keys derive from traffic key of respective direction. - Sending message to update keys would update only the traffic key in sending direction, regenerating low-level cipher keys and resetting the RSN in that direction. - Entropy from peer can't be explicitly be used. The best one could do here is to recommend mixing last received ratchet entropy from peer into own entropy to produce the random value to send when replying (when that happens). I don't think this is terribly more complicated than 1). But it is more complicated nevertheless. I don't see dropping the stronger full asynchronous constraint would simplify things, due to possibility of "crossed rekey" caused by finite "speed of light". Also, this would cause issues with DTLS: One would have to reliably transmit these rekeying messages, whereas previous DTLS are reliable only within handshake. Finally 3) Now the rekeying necressarily involves two messages. Doing this fully asynchronously seems just about impossible (updating one half- key at a time would hit "key caching" problem). Then it would be whole new logic for performing PK exchange. One can't reuse handshake because it would introduce thorny issues about tying to previous handshake and ensuring that state doesn't change in all sorts of unexpected ways. It also would need to somehow prevent crossing a key update. All in all, the complexity looks grealy greater than 1) or 2). -Ilari
- 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