Hello all, After our discussion in Berlin, I wanted to try to rally consensus over adding an explicit receive_generation field to the TLS 1.3 KeyUpdate message.
The KeyUpdate message allows one side of the connection to instruct the other to: 1) increment the receive-key generation, 2) de-trust and stop accepting data encrypted with receive-keys from earlier generations, and 3) advance the send-key forwards to at least the same generation if it isn't already (and send a KeyUpdate in the reverse direction as necessary). Because either side can generate a KeyUpdate message whenever they want, there's no way within the current draft to tell that this instruction has actually been carried out. For some applications, it would be helpful for an initiating side to receive a confirmation that the KeyUpdate (especially part #2, de-trusting the old receive-key) has taken effect: - An embedded device may wish to fully rotate the session keys before going to sleep. - A paranoid device might fully rotate the session keys before closing the session, with the hopes that the other side will de-trust and also delete the old session keys, so that a subsequent compromise doesn't betray the session plaintext. If an endpoint can't get confirmation that the other side has incremented the receive-key generation, it might use a higher-level mechanism to forcibly log out all open sessions from that user. - An endpoint that wishes to permit a read-only virus scanner or IDS will want to fully rotate the session before sharing the directional keys with the middlebox. Otherwise the middlebox could use them to become a MITM in at least one direction. Our proposal is to add a receive_generation field to the KeyUpdate message, so an initiating node can learn when an earlier KeyUpdate has taken effect. The KeyUpdate message would remain as async and non-blocking as it is currently. Pull request: https://github.com/tlswg/tls13-spec/pull/580 Earlier discussion: https://www.ietf.org/mail-archive/web/tls/current/msg19347.html and subsequent Cheers, Keith _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
