Subject: [DNSOP] Alissa Cooper's Yes on draft-ietf-dnsop-cookies-09: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 19 Jan 2016 16:10:31 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-cookies-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

----------------------------------------------------------------------
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.

(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).

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jan 2016 12:59:20 +1100

In message <[email-masked]>, "Alissa Cooper
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

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.

> 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.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 Jan 2016 08:28:06 -0500

Hi Alissa,

On Tue, Jan 19, 2016 at 8:59 PM, Mark Andrews <[email-masked]> wrote:
>> ...

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.

> 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
 [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Jan 2016 09:18:03 -0800

Hi Donald and Mark,

> On Jan 20, 2016, at 5:28 AM, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> getting shorter.

Ah, I had read it as being cumulative. Now I understand.

> But it is true that the jitter never lengthens from

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