Domain Name System (DNS) Cookies
draft-ietf-dnsop-cookies-10
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
(1) "To avoid rollover synchronization and predictability, it is RECOMMENDED that pseudorandom jitter in the range of plus zero to minus at least 40% be applied to the time until a scheduled rollover of a DNS cookie secret." Why is it recommended to only vary the interval in only the shorter direction (I'm assuming that is what is meant by "plus zero")? Then the interval will only ever get shorter, it seems. (2) It seems like there should be a recommendation about when to delete an old client cookie (e.g., after receiving a response to an outstanding request, or after some period of time with no response).
(Joel Jaeggli; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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?
(Terry Manderson; former steering group member) No Objection