Subject: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 17 Dec 2020 03:50:19 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-server-cookies-04: No Objection

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-server-cookies/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, I found it easy to read.  I have a couple of minor
questions/comments related to the lifecycles.

Section 3:

   Except for when the Client IP address changes, there is no need to
   change the Client Cookie often.  It is reasonable to change the
   Client Cookie then only if it has been compromised or after a
   relatively long period of time such as no longer than a year.  Client
   Cookies are not expected to survive a program restart.

It isn't clear to me why it is necessary to put an upper bound a on when a
client cookie needs to be changed at all.  What is the benefit of changing the
client cookie once a year?

5.  Updating the Server Secret

I think that it would be useful to remind the reader that server secrets are
expected to be updated on a semi-regular basis, as described in section 4.

Regards,
Rob

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 17 Dec 2020 12:59:52 -0500

Hi,

On Thu, Dec 17, 2020 at 6:50 AM Robert Wilton via Datatracker
<[email-masked]> wrote:
> ...

This is normal crypto hygiene. It is unsafe to trust a key/cookie
forever. Sooner or later it will get compromised by loss, accident,
whatever. Given this, an upper bound needs to be recommended. If it
were up to me, I would have said a month and that is in fact what it
says in RFC 7873 as follows:

   The longer a secret is used, the higher the probability that it has
   been compromised.  Thus, clients and servers are configured with a
   lifetime setting for their secret, and they roll over to a new secret
   when that lifetime expires, or earlier due to deliberate jitter as
   described below.  The default lifetime is one day, and the maximum
   permitted is one month.  To be precise and to make it practical to
   stay within limits despite long holiday weekends, daylight saving
   time shifts, and the like, clients and servers MUST NOT continue to
   use the same secret in new requests and responses for more than
   36 days and SHOULD NOT continue to do so for more than 26 hours.

Of course how often to change is a judgement call on which opinions will differ.

Assuming you do plan to change it periodically, another consideration
is operational. Say security considerations would mean you should
change it at least every 5 years. What is the chance that, after five
years, anyone will even remember to do it or even remember how to do
it? So the interval should be short enough that operational experience
is kept up.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Dec 2020 18:19:01 +0000

Hi Donald,

> -----Original Message-----
> From: Donald Eastlake <[email-masked]>
> Sent: 17 December 2020 18:00
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> dnsop-chairs <[email-masked]>; <[email-masked]> <[email-masked]>;
> Tim Wicinski <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-server-
> cookies-04: (with COMMENT)
> 
> Hi,
> 
[RW]

Yes, the explanation above all makes sense. But this is also why a year seems like a strange limit to me:

It is long enough that it doesn't seem to offer any great practical benefits, assuming both that it is bad practice to allow it to be compromised for a long time, and also that we care if it has been compromised.

Conversely, it is also long enough that it seems like implementations are more likely to be buggy (or not bother at all).  Suddenly things stop working after a year and nobody knows why, so they reboot the system and magically the problem goes away again for another year.

So, if this should be changed periodically, and it is easy and low impact to do so, then it would seem to make sense for it to change more frequently, say once a week?  It seems like my PC wants me to reboot for security updates every week or two anyway ...

Regards,
Rob

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 21 Dec 2020 15:14:05 -0500

> So, if this should be changed periodically, and it is easy and low impact to do so, then it would seem to make sense for it to change more frequently, say once a week?  It seems like my PC wants me…

Clients are not necessarily user systems that reboot weekly. They
might be recursive servers that run, potentially for years, without
reboot. But I mostly agree with your point and think a month is a
reasonable limit which is why it says that in RFC 7873. This sort of
thing is a judgement/engineering call.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]