Extended key update maximum epoch guidance

[martinthomson]

The cap on epoch in TLS/DTLS models the key update as a cipher that is subject to time-memory trade-off like others. Arguably this still applies with a full DH/KEM key exchange, but I am less happy with that conclusion. In effect, capping the number of epochs in this setting is akin to saying that there can't be more than 2^48 TLS connections, ever. It is still true that the birthday paradox applies to the combination of key and IV, but that would lead to a conclusion that you can't have more than 2^112 connections ever...a much larger number.

[hannestschofenig]

The text was copied from the TLS specification and needs to be adjusted.

I removed this text since it might confuse.

With a 128-bit key as in AES-128, rekeying 2^64 times has a high
probability of key reuse within a given connection. Note that even
if the key repeats, the IV is also independently generated, so the
chance of a joint key/IV collision is much lower. In order to
provide an extra margin of security, sending implementations MUST NOT
allow the epoch -- and hence the number of key updates -- to exceed
2^48-1. In order to allow this value to be changed later -- for
instance for ciphers with more than 128-bit keys -- receiving
implementations MUST NOT enforce this rule.

[martinthomson]

WFM.