[TLS] DTLS KeyUpdate

[Martin Thomson <[e-mail]>]

(From https://github.com/tlswg/dtls13-spec/issues/25)

Using the TLS process for KeyUpdate - as the current draft does -
leads to a suboptimal set of choices in implementations.

Sending KeyUpdate followed immediately by a key change means that
KeyUpdate isn't a reliable indicator of a key change at the receiver.
If the record containing the KeyUpdate is lost, then the receiver will
be unable to decrypt anything sent after it unless it looks at the
epoch and tries the new keys. That suggests a receiver design much
closer to the one in QUIC, where the KEY_PHASE bit (here, the low bit
of the epoch) is the only signal of a key update.

The receiver could buffer those records, but I don't see why it would
choose head-of-line blocking and a potentially-large memory commitment
over trialing the new epoch.

I would prefer a different design, even if it diverges from the TLS design.

1. That could be the same design as QUIC uses, with the epoch bit
signaling intent. The cost there is that you need to use the bit as an
acknowledgment of a key update, so you end up having to keep key
updates in lock step, even if no update is needed. If there are
asymmetric sending patterns, this isn't ideal.

2. Wait until the KeyUpdate is acknowledged before installing new
keys. When KeyUpdate is received, the receiver installs new keys, but
retains old keys on a timer (the holddown timer would do). The sender
waits for the ACK and starts using new keys when it sees it. The cost
here is that switching keys can't be immediate and it requires hooks
into the ACK handling logic, neither of which is ideal.

I have implemented the former and it's a little ugly, but I haven't
tried the latter.