Hiya, (I wouldn't put that much store on my specific response, but since you asked...) On 08/12/2020 01:23, Benjamin Kaduk wrote:
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.
Right. And whether there are any oddities, e.g. ways in which one ought not use the algorithm. Asking about that is IMO a good plan because once this gets used somewhere it'll be used again elsewhere so I'd prefer we know if/when that's ok or not. (Additionally, I'll admit a slight personal bias against adding new algorithms where we have existing ones that are fine - I figure that just costs more and damages interop for little or no benefit. That could be outweighed though if the new alg is already implemented and deployed for the purpose in question and/or if it's widely available in libraries.)
(2) whether the stated properties of SipHash are appropriate for the scenario we are using it for in this document.
For DNS cookies, I'd say it'd be very unlikely that this is not ok. Cheers, S.
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 <kaduk@xxxxxxx> 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, BenOn 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) ondrej@xxxxxxxOn 2. 12. 2020, at 22:15, Eric Rescorla <ekr@xxxxxxxx> 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 secdir@xxxxxxxx https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview_______________________________________________ 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
