As a quick update, we're still in the process of reviewing the proposed change. Time pending, we may throw it on the agenda for next week's meeting.
Best, Chris On Thu, Oct 14, 2021, at 3:53 PM, Christopher Wood wrote: > The PR's been updated to correct the editorial bug and clarify that the > epoch is truncated. We could also go with Martin's suggestion to make > the epoch 48 bits, yielding a 96-bit per-record sequence number. Or > something else. > > Please have another look. > > Thanks, > Chris > > On Wed, Oct 6, 2021, at 4:30 PM, Christopher Wood wrote: >> On Tue, Oct 5, 2021, at 8:36 PM, Martin Thomson wrote: >>> On Wed, Oct 6, 2021, at 12:58, Eric Rescorla wrote: >>>> This isn't dispositive, but note that TLS 1.3 doesn't include the epoch >>>> in its nonce at all. >>> >>> That strengthens the gut instinct some, as does the fact that QUIC >>> doesn't either. But neither of those protocols is exactly the same as >>> DTLS. DTLS doesn't place a hard end on any given epoch. TLS does. >>> QUIC's continuous packet number space creates a hard limit, even if >>> that limit isn't a single value. That suggests that some analysis >>> would be helpful. >>> >>> I'm less concerned about analysis than I am about getting the >>> specification bit right. >> >> FWIW, the intent of the change was to indeed truncate the epoch, as >> this is the variant that seems safest. I think you caught a couple >> places where that wasn't captured quite right, which we can fix. >> >> Best, >> Chris >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
