The discussion about KeyUpdate-related changes has trailed off so it is time to begin to bring the discussion to a close. It appears that there as if there is support to land https://github.com/tlswg/tls13-spec/pull/61. But, there’s still some discussion about how to add both P3 and P4 [0]. In the interest of making progress, we're instructing the editor to land PR#61 now.
Keith had argued for a restriction that wouldn't introduce any wire changes: i.e., forbid implementations from sending an update_not_requested KeyUpdate unless it is triggered by an update_requested KeyUpdate. Ilari has pointed out a limitation with this approach, but the question is: does the WG favor the restriction proposed by Keith? Please let the WG know by next Wednesday (9/14) so that we can come closure on this topic. Thanks, J&S [0] Where Keith suggested: P3 = A side can learn that P1 has been read by the other side. P4 = Neither side can cause the other to accrue an unbounded deferred write obligation; in fact the maximum accruable deferred write obligation is one KeyUpdate. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
