Hi Stephen, On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-dnsop-cookies-09: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - section 3: I think it'd have been good to mention the work > being done in dprive as another future protection that should be > compatible with DNS cookies.
Section 3 is intended to talk about existing standardized DNS security facilities. So I think it might be better in Section 9. How about: "Work is underway in the IETF DPRIVE working grop to provide confidentiality for DNS requests and responses which would be compatible with DNS cookies." > - I agree with Alissa's comment (2) See response there. > - section 9: I think you should note that (particularly > cleartext) client cookies allow correlation of client requests > for the duration of the client cookie lifetime, which may affect > other things the client does to try to avoid correlation and > that the set of lifetimes of all of those kinds of thing are > really interdependent. So e.g. if a client changes it's source > IP for privacy reasons, that may be defeated if the same client > cookie is still being used for DNS requests. See below. > - Thanks for handling the secdir review. That seems to have > ended up [1] with client cookie values that are quite similar > when only one bit of the server IP varies. Yet, [FNV] says that > it has "high dispersion." I don't know FNV well enough to know > if what Yoav called the "disturbingly similar" values in [1] > might allow for guessing cookie values if one has ever seen a > cookie value or not, but I'd be interested in chatting about > that. (In a non-blocking sense:-) In general, I'd prefer if you > recommended HMAC-SHA256 rather than FNV myself - why isn't that > really a better thing to put in the appendices? (Yeah, > performance, I know, but is the delta between FNV and > HMAC-SHA256 really so significant these days, compared to the > time it takes to lookup the DNS data itself?) > > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html The draft has been changed in version -09 to reverse the order of the inputs to FNV and include a statement that the older order is weaker. Indeed, in the earlier draft an attacker with a similar IP address (differs in only a few low order bits) to their target could send some requests to the server and, based on the Server Cookie the attacker got back for themselves and the bits that differ between the attacker's and target's IP addresses could probably guess the target's Server Cookie with relatively few tries. However, with the reversed order of inputs, the changes will cascade and I believe this problem is eliminated. The Client Cookie calculation occurs in the client, which might be feeble. The lookup of the DNS data itself occurs in the server, which is likely to be more powerful. > - Can't an access point/router that was once on path but is no > longer abuse the client cookie (that it once saw go by) when > that client is still using the same value later to talk to the > same server via another n/w path? Is that worth a mention in > the security considerations? What'd be the effect? I wondered > why you didn't include e.g. the client IP in the input in > Appendix A.1 to avoid this issue? We really didn't think about the client changing its IP address. Seems like some clients will very rarely change their IP address while others might change fairly often for privacy or mobile roaming reasons. I have no problem adding the client IP to the inputs to the Client Cookie. Since the client is the only thing that needs to recognize its own cookies, any existing implementations will continue to work and will not be affected by a changed recommendation for calculating Client Cookies. The possibility of using the Client Cookie for tracking is also a good point that should be mentioned in the Security Considerations. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
