Domain Name System (DNS) Cookies
RFC 7873

Note: This ballot was opened for revision 08 and is now closed.

Alissa Cooper Yes

Comment (2016-01-19 for -09)
No email
send info
(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) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-01-20 for -09)
No email
send info
- 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?

(Brian Haberman) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection