Re: [TLS] DTLS 1.3 epochs vs message_seq overflow
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 On Behalf Of David Benjamin Sent: Friday, April 12, 2024 1:16 AM To: Cc: Nick Harper Subject: Re: [TLS] DTLS 1.3 epochs vs message_seq overflow On Thu, Apr 11, 2024 at 7:12 PM David Benjamin mailto: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
Re: [TLS] DTLS 1.3 epochs vs message_seq overflow
On Thu, Apr 11, 2024 at 7:12 PM David Benjamin 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
[TLS] DTLS 1.3 epochs vs message_seq overflow
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
