ntp.conf changes for NTS
James Browning
jamesb.fe80 at gmail.com
Sun Feb 3 02:39:56 UTC 2019
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.
More information about the devel
mailing list