On Wed, Dec 2, 2020 at 1:49 PM Stephen Farrell <[email protected]> wrote:
> > Hiya, > > On 02/12/2020 21:38, Willem Toorop wrote: > > Op 02-12-2020 om 21:37 schreef Stephen Farrell: > > > > <snip> > > > >>> ad 2) we need a value that’s synchronized well enough and monotonic. > >>> I honestly don’t see any value in using 64-bit value here. Using > >>> unixtime has a value in itself, it’s a well-known and there’s a > >>> little room for any implementer to make a mistake in an > >>> implementation. The interoperability is more important than the > >>> actual value of the counter. It’s write only counter, nobody is going > >>> to interpret it after it has been generated, and it’s wide enough to > >>> prevent brute forcing. > >> > >> So what happens after 2038? That's really not v. far in the > >> future any more. > > > > The draft states that `All comparisons involving these fields MUST > > use "Serial number arithmetic", as defined in [RFC1982]'. So it can not > > be used to compare differences larger than 68 years, but comparisons of > > cookie timestamps are more in the "hours" order of magnitude. > > Sorry for being dim, but is clear what value to put > in those 4 octets in say 2039 such that different > implementations will do the right thing? I did glance > at rfc1982, so there may be very far-sighted text > in there that I missed:-) And it may even be fine > for this purpose if different servers differ by a > second or so at that point, but even if so, it may > be a bad plan to leave that unspecified in case > other timestamps use the same code. > The reference to RFC1982 pretty much implies use of modulo arithmetic. Maybe it would help to spell it out? (Basically, calculate seconds since Jan 1 1970 at 0000 UTC, and if the value is > 2^32, take the remainder mod 2^32.) The RFC1982 specifies how the differences should be handled, so regardless of which one is 0 and which one is 1 (or 2^32 - 1), the difference yielded is a small number (i.e. 1). This handles any relative time window less than 68 years, at any time in the future (2038 or 2106 or 2256 or 22209.) Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
