On Jul 6, 2015, at 8:00 AM, Donald Eastlake <d3e...@gmail.com> wrote: >> Substantial: >> >> In Sections 4.1 and 4.2, it says that the cookies MUST NOT be the same for >> all recipients. This should be SHOULD NOT, to match the SHOULDs above. If an >> implementation does a stupid and uses the same cookies everywhere, it is no >> worse off for it, it just isn't getting as much protection as expected. (If >> I'm wrong about that latter bit, then the reason for the MUST NOT should be >> given in both sections.) > > No. The document claims that cookies provide weak security. If exactly > the same cookie can be used for everyone, then that claim is wrong and > it provides no security, at least for servers -- anyone could query > the server using their true IP address, take the one cookie from the > reply, and replay that cookie to the server in forged IP address > queries, etc. > > It would be nice to be able to say that implementations MUST provide a > different cookie for every recipient, but with 64 bit pseudorandom > functions, there will always be a residual probability of hash > collisions. But I can conceive of no reason to allow an implementation > to claim to be conforment while providing no security. > > The "SHOULDs" you refer to relate to implementation suggestions. The > MUST NOT is the rock bottom minimum requirement that all > implementations have to meet.
OK, this is fair. Please consider adding "In order to maintain the security properties of this protocol," to the beginning of each of those MUST NOT sentences. >> I continue to be concerned that draft-eastlake-fnv, which is likely to be >> used by implementations of cookies, is still just a draft, not an RFC. It's >> not for this WG to do, but anyone implementing this draft should read that >> draft, send comments, and let's get that published as well. > > My apologies for being slow on completing the fnv draft. I have made > substantial progress on that but I'm quite busy this week and next. I > plan to post a revision during the IETF meeting week. If you want to > apply more pressure to me :-) you could suggest that the reference to > fnv from cookies be made a normative reference. After all, the draft > says you SHOULD use something at least as strong as fnv... No need for that. It's OK for this draft to point to a draft of FNV because the current draft feels good enough to implement from (but I say that not having done so!). But do keep moving on the FNV draft: it would have been useful to have this be an RFC reference, and there are lots of other places in the IETF where people won't downref to a draft. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
