On Thu, Aug 18, 2016 at 12:30:03AM -0700, Keith Winstein wrote: > I think it's probably possible to make everybody happy here. > > I appreciate the need to avoid allowing the other side to create an > unbounded deferred write/compute obligation. I also think it's > valuable to preserve the ability for "either side to force an update > to the entire connection," and obviously I think it's valuable for the > initiating side to get an ack that that has happened (hence PR > #426/#580). > > To mitigate the unboundedness issue, what would you think about this option: > > 1) Keep everything the same as the current draft, but > 2) Add this text: "An implementation MUST NOT advance its current > sending generation to be greater than its current receiving generation > plus one."
That wouldn't work very well in highly asymmetric situations. One could add rule that allows rekeys in excess of that limit if RSN is above some threshold. Such RSN thresholds would greatly slow down KeyUpdate spam (e.g. reaching 2^32 takes 84GB at minimum). Also, for DTLS, one would need limits like this to avoid exessive key updating. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
