Hiya, On 02/12/2020 22:07, Willem Toorop wrote:
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 thingWell 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.
Ah. I missed that "unsigned." (Does that mean implementers might also?)
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).
So the buggy case would be where a server re-constructs the input to the hash after some kind of round-trip of the octets (to e.g. struct tm or something and then back to time_t and to network byte order) at which point you could I think get failures depending on who implemented what incorrectly. That kind of thing has been seen before (even if it seems a bit mad;-) FWIW, I'd say it's worth a few more words to try reduce the probability of such failures happening, e.g. maybe just highlighting the "unsigned/2106" point you made above would be enough. But, if the WG don't want to do that, that's also fine by me. Cheers, S.
Cheers, -- WillemI 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, -- WillemCheers, 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
Attachment:
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
