On 2/2/19, Gary E. Miller via devel <devel@ntpsec.org> wrote: > Yo James! > > On Sat, 2 Feb 2019 13:44:12 -0800 > James Browning via devel <devel@ntpsec.org> wrote: > >> >> What you almost need is a cookie extension to trigger a rekeying >> >> periodically. >> > >> > Yes. Sad the Proposed RFC is silent on the subject. Seems a gaping >> > hole to me. >> > >> >> You might want to look at the 2nd? Commit of mr 902 and >> >> then point and laugh. >> > >> > GitLab does not consecutively number commits. Whis one do you >> > mean? >> >> https://gitlab.com/NTPsec/ntpsec/merge_requests/902/diffs?commit_id=ac0ab3cb0fbbe8d9d2b3f7b43340ba0bc0d6bd30 >> >> "drop/revise" of "Nts pass3" > > > I assume you mane this:
Yep, this is it. > .. (optional) a timestamp when to stop honoring the current cookie > series > > Good. More correct to say stop using the same C2S/S2C Sometime after I wrote that I have the idea of using an MJD number for this and the following. I haven't got around to putting it in the file. There is always tomorrow. > .. (optional) a timestamp when the current cookie series began (for > expiration) > > Similar, use one or the other. Well, the Intention was that only one of the four would be used and the other four are alternatives. > .. (optional) a number of cookies remaining before series expiration. > > Useless. The artacker just keeps presenting the same cookie. > > .. (optional) the number of cookies (estimated) since series began for > expiration. > > Useless. The attacker just keeps presenting the same cookie. Good points. I think I mostly put them in there to cover all the possibilities I could think of ATM. > This should be in the Proposed RFC. Other implementations will get it > wrong. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
