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