On Wed, Dec 2, 2020 at 10:32 AM Ondřej Surý <ond...@isc.org> wrote:
> 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. > Well hash tables are an application with somewhat different security properties than MACs, so I don't think this is dispositive. I concur with Stephen that CFRG should sign off on the use of SipHash here. With that said, how does SipHash compare to GMAC in terms of performance? -Ekr > 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 < > nore...@ietf.org> 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. > > > > > > > > > > _______________________________________________ > secdir mailing list > sec...@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
