Stephen, ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I can’t speak for Willem, but I am confident enough to make the decision. SipHash is widely used for hash tables virtually anywhere now. 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 implementor 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. 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. > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
