[TLS] DTLS 1.3 epochs vs message_seq overflow

[David Benjamin <[e-mail]>]

Hi all,

In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed
the epoch number from 16 bits to 64 bits, though with a requirement that
you not exceed 2^48-1. I assume this was so that you're able to rekey more
than 65K times if you really wanted to.

I'm not sure we actually achieved this. In order to change epochs, you need
to do a KeyUpdate, which involves sending a handshake message. That means
burning a handshake message sequence number. However, section 5.2 says:

> Note: In DTLS 1.2, the message_seq was reset to zero in case of a
rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS
1.2 shares similarities with a post-handshake message exchange in DTLS 1.3.
However, in DTLS 1.3 the message_seq is not reset, to allow distinguishing
a retransmission from a previously sent post-handshake message from a newly
sent post-handshake message.

This means that the message_seq space is never reset for the lifetime of
the connection. But message_seq is a 16-bit field! So I think you would
overflow message_seq before you manage to overflow a 16-bit epoch.

Now, I think the change here was correct because DTLS 1.2's resetting on
rehandshake was a mistake. In DTLS 1.2, the end of the previous handshake
and the start of the next handshake happen in the same epoch, which meant
that things were ambiguous and you needed knowledge of the handshake state
machine to resolve things. However, given the wider epoch, perhaps we
should have said that message_seq resets on each epoch or something. (Too
late now, of course... DTLS 1.4 I suppose?)

Does all that check out, or did I miss something?

David