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. 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
