[quicwg/base-drafts] MAX_KEY_UPDATES frame (yet another proposal to solve the key retirement problem) (#2504)

[Kazuho Oku <[e-mail]>]

This PR is yet another attempt to resolve #2214, along with #2237 and #2492. The principle behind the PR is to align the design of key updates to other parts of the protocol as much as possible, by reusing the design pattern we use to communicate the maximums.

* Does not change how the Initial keys are dropped.
* Introduce a MAX_KEY_UPDATES frame, that is similar to existing MAX_* frames.
  * The frame carries explicitly the cumulative number of key-updates being permitted.
  * No special retransmission rules are required, because the maximum number is carried as a field within the frame.
* Initial exchange of MAX_KEY_UPDATES frame indicates the completion of the handshake.
  * Disposal of 0-RTT and Handshake keys are negotiated using the frame.
* MAX_KEY_UPDATES carrying a maximum count of zero indicates the peer that handshake is complete, but key update is prohibited.
  * I think that this is the direction we are heading to. All the three proposals use explicit signal to communicate the disposal of the keys, which in turn means that the key-update can be forbidden by not sending the signal.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2504

-- Commit Summary --

  * MAX_KEY_UPDATES frame

-- File Changes --

    M draft-ietf-quic-tls.md (115)
    M draft-ietf-quic-transport.md (33)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2504.patch
https://github.com/quicwg/base-drafts/pull/2504.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2504