On Fri, Nov 6, 2015 at 6:39 PM, 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). As I said above, I agree that the specification should provide some guidance on how often you should re-key for a given cipher based on the number of records/cipher blocks (whatever is more convenient for analysis). This guidance should be derived from the kind of analysis Watson and Dave McGrew have done for these algorithms, and, as Watson's analysis suggests, is likely to be algorithm specific. I don't believe time-based guidance is useful here, given that it's highly situation specific rather than derived from reasoning about the properties of the cipher. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
