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
