On Thu, Apr 11, 2024 at 7:12 PM David Benjamin <david...@chromium.org> wrote:
> 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?) > Alternatively, if we think 65K epochs should be enough for anybody, perhaps DTLS 1.4 should update the RecordNumber structure accordingly and save a few bytes in the ACKs. :-) > Does all that check out, or did I miss something? > > David >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
