On Thu, Dec 17, 2020 at 1:19 PM Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > 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 ...
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 d3e...@gmail.com > 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
