On Fri, Nov 6, 2015 at 7:50 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir <ynir.i...@gmail.com> wrote: > >> >> > On 7 Nov 2015, at 11:39 AM, Dave Garrett <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). >
To be clear, I'm not saying that there aren't other reasons for rekeying, just that the problem agreed to address is the one above. -Ekr > Are we OK with just generating new keys from the same internal state (so >> the handshake message is pretty much only “rekey now”), > > > I believe this is what we agreed both in Seattle and in Prague. > > -Ekr > > > >> or >> Do we want freshness (usually in the form of new mutual nonces, or >> Do we want forward secrecy so another diffie-hellamn exchange? >> >> Yoav >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
