Extended key update epoch

[martinthomson]

In TLS 1.3 and DTLS 1.3, the KeyUpdate message immediately precedes a change of keys.

Here, the initiator of a key update seems to change epoch after receiving a message from its peer, so that when its peer receives records encrypted with the new epoch it either has no indicator (in TLS) or only the epoch marker (in DTLS). If possible, I would prefer to avoid the use of trial decryption.

[hannestschofenig]

With a Diffie-Hellman I need two messages and I had two choices:

• Update the application traffic secret in both directions, or
• Update the application traffic secret in the senders direction only.

I have decided to go for the latter approach since this aligns better with DTLS where a ACK in response to a Key Update is needed anyway. The downside is that two DH operations are needed to update the traffic secrets in both directions. Since such a key update is likely to be needed for higher-end devices, this does not seem to be a big issue.

[martinthomson]

Ah, that is helpful, but it doesn't address the concern. I think that you need a third message here:

1. Initiate key update
2. Provide shares
3. Indicate change of epoch/finalize

As I indicated, DTLS probably works without message 3, but TLS won't (at least without trial decryption).