<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Sat, Feb 2, 2019, 12:46 PM Gary E. Miller 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">Yo Hal!<br>
<br>
On Sat, 02 Feb 2019 12:36:10 -0800<br>
Hal Murray via devel <<a href="mailto:devel@ntpsec.org" target="_blank" rel="noreferrer">devel@ntpsec.org</a>> wrote:<br>
<br>
> But there is another pair of keys: C2S and S2C.  They are used to<br>
> authenticate and encrypt traffic between client and server.  There is<br>
> no explicit mechanism to roll them over - nor is there a need for one.<br>
<br>
Really?  So unlimmited numbers of packets with identical C2S, S2S<br>
and master key, differing only int ehnonce is not a problem?<br>
<br>
Pretty much every crypto algorithm I know of has a recommended<br>
maximum number of uses.  Allowing these two to be used unlimited times<br>
is violating absic crypto principles goint back to well before how<br>
Enigma, and other ciphers, were broken.<br>
<br>
> But if no packets are lost, C2S and S2C will be used forever.<br>
<br>
Yeah, bad.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">What you almost need is a cookie extension to trigger a rekeying periodically. You might want to look at the 2nd? Commit of mr 902 and then point and laugh.</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"> <br>
</blockquote></div></div></div>