Hi Donald and Mark, > On Jan 20, 2016, at 5:28 AM, Donald Eastlake <d3e...@gmail.com> wrote: > > 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.
Ah, I had read it as being cumulative. Now I understand. > 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. All sounds fine to me, it just seems like if you acknowledge that keeping a cookie around longer than necessary has some risk associated with it, it’s worth giving explicit guidance about deleting it. But “until there is no longer an outstanding request associated with it” seems like a fine guideline. Alissa > > 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
