[TLS]Re: DTLS 1.3 epochs vs message_seq overflow

[David Benjamin <[e-mail]>]

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