Hi, I'll just reply where Mark did not:
On Sun, Jul 5, 2015 at 7:48 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had > not looked at carefully in some time. In short: it looks great, the document > is complete and easy-to-read, and we probably should have done this nearly a > decade ago when Donald started the work. Thanks. > 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. > ... > > Editorial: > > In Section 2.2, "the Dan Kaminsky attack" sounds like an attack by someone, > not described by someone. The parenthetical can probably be removed, or > turned into an informative reference from something that Dan wrote. OK. > In Section 5.2, second paragraph, "as before" is unclear. This probably means > "as if no COOKIE OPT option had been sent", but it should be explicit. OK. > Procedural: > > ... > > > 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... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
