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