> On 7 Nov 2015, at 12:50 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > > > On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarr...@gmail.com > > <mailto:davemgarr...@gmail.com>> wrote: > > > > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > >> Update: we discussed this extensively in Yokohama and based on Watson's > >> feedback and offline comments from David McGrew, the consensus was that we > >> needed to add some sort of rekeying mechanism to support long-lived flows. > >> Expect a PR on this next week. > >> > >> Note: We'll still need guidance to implementations on when to re-key, but > >> we don't expect to have a hard protocol limit. > > > > If re-keying is back up for discussion, let me restate my request for it to > > be routine, rather than only an niche-case feature. Any re-key schedule > > should be considered valid, but the spec should set a "SHOULD"-level > > requirement that the minimum be once every N hours or M terabytes, > > whichever comes first (where N & M are some bike-shedable numbers with some > > expectation of randomization in values for each period). > > N and M will be different depending on the algorithms, no? > > I think before we start with pull requests we should be certain of what the > requirements are for this rekeying. > > These were discussed extensively both in the interim and at IETF. The purpose > of rekeying in this context is to deal with cryptographic exhaustion, namely > having more ciphertext under the same key than is safe for a > given algorithm (where safe is defined by an analysis like the one Watson > has posted upthread).
Sure, but once you provide a rekeying capability, the connection can keep going forever. That means you could be running for weeks and terabytes without injecting any freshness, and the the internal state remains in memory for all that time. A compromise of the state in the future allows decrypting everything since the beginning of the connection. This is not the same as having to tear down the connection at the cryptographic exhaustion. It is possible to get this kind of forward secrecy if the rekeying includes modifying the internal state in a non-reversible way such as hashing the master secret into a new master secret (or using HKDF-Extract), but that hurts the goal of having each side recycle the keys at its own pace (which is a strange goal, because my security depends on the security of my receiving keys as much as it depends on the security of my transmitting keys). Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
