Hi Donald, > -----Original Message----- > From: Donald Eastlake <d3e...@gmail.com> > Sent: 17 December 2020 18:00 > To: Rob Wilton (rwilton) <rwil...@cisco.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-dnsop-server-cook...@ietf.org; > dnsop-chairs <dnsop-cha...@ietf.org>; <dnsop@ietf.org> <dnsop@ietf.org>; > Tim Wicinski <tjw.i...@gmail.com> > Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-server- > cookies-04: (with COMMENT) > > Hi, > > On Thu, Dec 17, 2020 at 6:50 AM Robert Wilton via Datatracker > <nore...@ietf.org> wrote: > > > > Robert Wilton has entered the following ballot position for > > draft-ietf-dnsop-server-cookies-04: No Objection > > > > ... > > > > ---------------------------------------------------------------------- > > 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? > > 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. [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 > > 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 > d3e...@gmail.com > > > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
