(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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
