Op 02-12-2020 om 22:49 schreef Stephen Farrell: > > 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 Well the text does specify an "32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC", so because of the "unsigned" the wrap to 0 is only in 2106, not 2038. But even then, in 2106, it should not be a problem to check the age of a cookie because of the rfc1982 comparison (which takes care of the wrap) and the fact that Server Cookies will not be older than hours (and not years). Cheers, -- Willem > 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. > > Cheers, > S. > >> >> Cheers, >> -- Willem >> >>> >>> Cheers, >>> S. >>> >>>> >>>> Cheers, Ondřej -- Ondřej Surý — ISC (He/Him) >>>> >>>>> On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker >>>>> <noreply@xxxxxxxx> wrote: >>>>> >>>>> Reviewer: Stephen Farrell Review result: Has Issues >>>>> >>>>> I see two issues here worth checking: >>>>> >>>>> 1. I don't recall SipHash being used as a MAC in any IETF standard >>>>> before. We normally use HMAC, even if truncated. Why make this >>>>> change and was that checked with e.g. CFRG? (And the URL given in >>>>> the reference gets me a 404.) >>>>> >>>>> 2. Is it really a good idea to use a 32 bit seconds since >>>>> 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours >>>>> since then or seconds since some date in 2020 would be better. >>>>> >>>>> Here's a couple of nits too: - section 1: what's a "strong >>>>> cookie"? - "gallimaufry" - cute! but not sure it'll help readers to >>>>> learn that word. >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ DNSOP mailing list >>>> DNSOP@xxxxxxxx https://www.ietf.org/mailman/listinfo/dnsop >>>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/dnsop >> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
