<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Sat, Feb 2, 2019, 5:27 AM Hal Murray via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> Yes, you'd need implausible to impossible lifetimes of the client/server<br>
> pairing for these to ever become a problem.  But again, when key rollover<br>
> gets implemented as indicated in the RFC, those will stop being useful on the<br>
> second rollover.<br>
<br>
What stops being useful when K rolls over is old cookies.<br>
<br>
C2S and S2C are used to authenticate the packets and also to encrypt new <br>
replacement cookies from server to client.  There is no roll over mechanism <br>
for C2S or S2C.  They get refreshed if you go through NTS-KE again, but that <br>
doesn't happen during normal operations.  You need to do something like drop 8 <br>
packets in a row.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">IIRC the previous key is kept for a rotation. Unless you are using something like poll 14+ it shouldn't be a problem.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>