Stephen Farrell has entered the following ballot position for draft-ietf-dnsop-cookies-09: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ ---------------------------------------------------------------------- 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. - I agree with Alissa's comment (2) - 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. - 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 - 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? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
