Subject: [quicwg/base-drafts] 85db1f: Rewrite key update section

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Sep 2019 19:59:50 -0700

Branch: refs/heads/rework-key-update-2
  Home:   https://github.com/quicwg/base-drafts
  Commit: 85db1f71811872bc01e4ac3692e545620258b82e
      https://github.com/quicwg/base-drafts/commit/85db1f71811872bc01e4ac3692e545620258b82e
  Author: Martin Thomson <[email-masked]>
  Date:   2019-09-19 (Thu, 19 Sep 2019)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Rewrite key update section

This makes some significant editorial changes to the key update section,
hopefully making the various activities clearer and more explicit.

In the process, I am also trying to address #2792, which is the timing
sidechannel created by having the generation of updated keys inline with
packet processing.  In doing so, I'm suggesting that endpoints create
the next keys at some time after the key update happens.  Right now, I'm
thinking 1-2 PTOs is probably close enough to workable.  I've limited
this at 3PTO.  This is, however, just a (firm) suggestion at this stage.

For endpoints that only want to keep 2 sets of keys, this is probably
the right time frame, especially if we keep the current advice for 3PTO
before a subsequent update.

The effect of this is that attempts to update at certain times could
cause all packets after the update to be discarded.  That would only
happen if implementations consistently ignored advice on update
frequency, so I think that's tolerable, but I'd like input on this.

(This also attempts to take up the advice from the other, older PRs on
this subject.)

Closes #2792, #2791, #2237.