ntp.conf changes for NTS

[James Browning]

On 2/2/19, Gary E. Miller via devel <devel at ntpsec.org> wrote:
> Yo James!
>
> On Sat, 2 Feb 2019 13:44:12 -0800
> James Browning via devel <devel at 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.