[TLS] closing KeyUpdate

[Sean Turner <[e-mail]>]

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.