<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Thu, Jan 17, 2019, 5:54 PM 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>
Ian Bruene said:<br>
> NTS-KE needs cookie generation because it has to render onto the client  the<br>
> initial cookie stock. <br>
<br>
Right.  But it doesn't actually have to generate them itself.  It could also <br>
get them from the NTP-server.<br>
<br>
The idea is to take advantage of a connection to the NTP-server to offload as much complexity as possible.  What does the NTP-KE-server do with the master key?  Can we push all that to the NTP-server?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You would have to shove all of the complexity into an ntpd thread. OpenSSL *seems* to be annoyingly non-reentrant which would limit you to switching between ntp w/ nts and nts-ke. One particular daemon seems to work around that by generating lots of processes.</div><div dir="auto"><br></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">
I like Gary's suggestion of making most of the NTS-KE-client a library so we can package it stand alone or with NTP-client.  I think the same applies to NTS-KE-server.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I tried something not completely unlike that in !842 but it was buggy, nonfunctional and leaky. </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>