Hi Alissa, On Tue, Jan 19, 2016 at 8:59 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <20160120001031.9209.94235.idtrac...@ietfa.amsl.com>, "Alissa > Cooper > " writes: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-dnsop-cookies-09: Yes >> >> ... >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> (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. > > No. There is the desired lifetime and the scheduled rollover. The > scheduled rollover is computed from the desired lifetime not the > previous scheduled rollover. This could be done once creating a > interval timer unique to this client or whenever the timer fires.
Not sure exactly what you meant. As Mark points out, it does not keep getting shorter. But it is true that the jitter never lengthens from the scheduled rollover, only shortens. Lengthening would increase the time during which the Cookie could be attacked and thus reduces security. Shortening a bit improves security. Probably not very relevant but I would also point out that this jitter formulation (+0%, -x%, where x is at least 40) is exactly the same as the jitter applied to IS-IS routing messages. >> (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). > > Why? There is no recommended time for when to abandon a DNS request > without a cookie. A old cookie is only useful for as long as the client > is expecting a reply which should be self evident. You match the sent > client cookie with that in the reply not some arbitary client cookie. A useful DNS client has to remember its outstanding requests including their ID field and match them against responses as long as it is expecting that a response might arrive. It seems natural to keep the Client Cookie with the other request information. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
