Hi Ondřej, Thanks for this detailed writeup; it really helps bring clarity to the current situation.
In light of the follow-ups from others, it seems that there are actually two distinct but somewhat entangled issues: (1) whether SipHash is a strong cryptographic hash function that delivers its stated properties. (2) whether the stated properties of SipHash are appropriate for the scenario we are using it for in this document. I had initially assumed that Stephen's review was asking about (2), but for the most part we tend to ask CFRG about things like (1). So, while I agree that it's valuable to get input from the CFRG on (1) and am willing to start the conversation there if needed, I would also like to get Stephen's (or anyone else's really) input about question (2). I suspect that we are okay in that regard, not least because of the other similar usage that you describe, but request that the analysis of what properties we need from a hash function for this use case (and that SipHash meets them) be included in a future version of the draft. Thanks again, Ben On Fri, Dec 04, 2020 at 10:14:29PM +0100, Ondřej Surý wrote: > 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
