Hi Benjamin, I did not used appeal to authority as an argument, but I’ve just provided examples that SipHash has been implemented in the similar scenarios and there hasn’t been reported issue with the choice for years now.
Using fast PRF (pseudorandom function) for the DNS Cookies is a good choice because it matches the required properties - it needs to be fast and secure in a sense that attacker can’t compute neither the key nor the output of the function. DNS Cookies are not MACs. Sorry for the misnomer of the brute force - what I meant was a protection against a replay attack. I’m just currently very tired with day to day job. Please note that DNS Cookies doesn’t protect the actual DNS message payload, it merely provide means to establish trust between the client and the server as to distinguish between a legitimate and spoofed traffic, so different policies can be used - Response Rate Limiting (RRL) could be turned off for DNS messages with cookies or when under attack it could require fallback to TCP for DNS queries without the DNS Cookie. The DNS cookies doesn’t protect the actual content in any way, neither it does protect the communication from the on path adversary. In that regard, the client cookie is just nonce (and it’s just convenient to use same algorithm to generate it, but it could be output from CSPRNG as well) and the server cookie is a cryptographic primitive that uses the client nonce, key and timestamp to construct the server cookie. Such server cookie is used by the DNS client to authenticate to the server (it’s shared secret, but it requires no per-client state on the server). Just to repeat, the actual payload (DNS message) is not protected by the DNS cookie. If the DNS server could keep a state for every DNS client, a CS random number would be as good as the output of the SipHash. I might not be a cryptographer as my daily job, but I am reasonably confident that SipHash has matching properties, it hasn’t been broken as of today. Also all DNS vendors have agreed to make this choice and the RFC here is merely a way how to ensure interoperability between various implementations. (Typing this on phone, so excuse any irregularities in the text.) Ondrej -- Ondřej Surý — ISC (He/Him) > On 4. 12. 2020, at 21:37, Benjamin Kaduk <[email protected]> wrote: > > Hi Ondřej, > > Just because someone else does something, even a "big name", doesn't > necessarily make it a good idea for us to also do it. > We should be able to justify our algorithm choices on cryptographic > principles, not just appeal to authority. > > In a similar vein, you said something about the 32-bit timestamp being wide > enough to prevent brute-force attacks. Could you say a bit more about what > attacks those are that are being prevented? I'm not really seeing how the > width of the timestamp comes into play for that concern, just from a quick > skim of the document. (Timestamps tend to not provide much protection > against brute force by themselves, since time is relatively guessable, > especially to seconds precision.) > > Thanks, > > Ben > >> On Wed, Dec 02, 2020 at 11:18:29PM +0100, Ondřej Surý wrote: >> SYN cookies in both Linux and FreeBSD uses siphash. >> >> * FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 >> (since 2013) >> * Linux: >> https://github.com/torvalds/linux/commit/fe62d05b295bde037fa324767674540907c89362#diff-14feef60c3dbcf67539f089de04546c907233cbae09e1b2dd2c2bc6d6eae4416 >> (since 2017) >> >> I believe that the SYN cookies have exactly the same properties as DNS >> cookies. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> [email protected] >> >>>> On 2. 12. 2020, at 22:15, Eric Rescorla <[email protected]> wrote: >>> >>> Well hash tables are an application with somewhat different security >>> properties than MACs, so I don't think this is dispositive. >>> >> >> _______________________________________________ >> secdir mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
