Circling back to this thread, I think the best thing to do is to just concede we failed to actually increase the epoch space and permit implementations to keep it 16-bit. We can try again in DTLS 1.4, or just fully revert to a 16-bit epoch space.
I've filed the following errata to do this: https://www.rfc-editor.org/errata/eid8048 https://www.rfc-editor.org/errata/eid8050 David On Tue, Apr 16, 2024 at 2:16 AM Tschofenig, Hannes < hannes.tschofe...@siemens.com> wrote: > Hi David, > > > > thanks for your reviews and the details comments. > > > > Let me search for the exchanges that lead to the increase in the epoch > space. I recall that this was very late in the process based on feedback > from John, who noticed that the smaller epoch space helps IoT communication > but not the DTLS use in SCTP. > > > > Regarding your statement: “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“. Possibly correct. I am going to ask the > SCTP community for feedback to find out whether that is also true for them. > > > > Ciao > > Hannes > > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *David Benjamin > *Sent:* Friday, April 12, 2024 1:16 AM > *To:* <tls@ietf.org> <tls@ietf.org> > *Cc:* Nick Harper <nhar...@chromium.org> > *Subject:* Re: [TLS] DTLS 1.3 epochs vs message_seq overflow > > > > 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 To unsubscribe send an email to tls-le...@ietf.org
