On Wed, Dec 2, 2020 at 1:49 PM Stephen Farrell <stephen.farrell@xxxxxxxxx> 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.)
(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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
