Skip to main content

Domain Name System (DNS) Cookies
draft-ietf-dnsop-cookies-10

Yes

(Joel Jaeggli)

No Objection

Alvaro Retana
(Alia Atlas)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

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

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes (2016-01-19 for -09)
(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

Yes (for -08)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -09)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -09)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -09)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -09)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -09)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -09)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -09)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -09)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-01-20 for -09)
- 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

No Objection (for -09)