<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 01/06/2019 02:55 PM, Gary E. Miller
      via devel wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20190106125528.0fe7d5b6@spidey.rellim.com">
      <pre wrap="">Seems to me that Section 6 of the proposed RFC defines this pretty well.
Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE) are.
</pre>
    </blockquote>
    <br>
    Partially. It gives an example of a way to do it, but no protocol or
    message scheme; just what the cookies could look like. It is missing
    the primary piece that you want in that section of the design.<br>
    <br>
    <blockquote type="cite"
      cite="mid:20190106125528.0fe7d5b6@spidey.rellim.com">
      <pre wrap="">Hardly qualifies as a transaction as there is no reciprocity (See the
dictionary).  In the dark past, either the NTPD told the NTS-KE what
keys to use, or vice versa.  Not even a need for an ACK.
</pre>
    </blockquote>
    <br>
    Fair enough, I'm not versed in the terminology here.<br>
    <br>
    <blockquote type="cite"
      cite="mid:20190106125528.0fe7d5b6@spidey.rellim.com">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">"It's whatever is needed to verify the cookie from Alpha."
</pre>
      </blockquote>
      <pre wrap="">
Yes, the blob as defined in Section 6.

</pre>
      <blockquote type="cite">
        <pre wrap="">Whatever needs to be communicated on that channel it can't be
verifying cookies and also be "only an occasional ???". Verifying
cookies means every single ntp packet that comes in to Charlie has to
be checked with Delta.
</pre>
      </blockquote>
      <pre wrap="">
Nope.  Reread the Proposed RFC.  NTS-KE and NTP agree before hand on
some long lived keys to use.  They actually don't need to 'agree'.
Either the NTS-KE tells the NTP, or vice versa.  Maybe no need for any
negotiation.  Then use them for hours, days, weeks or months.

Section 6 proposes a simple means to keep generating new short term
keys fomr old keys, so no need for further communication between the
NTS-KE and NTPD.  Just once is enough.

Not to say that it can't, or shouldn't, get a bit more complicated, but
it is not required.
</pre>
    </blockquote>
    <br>
    Verifying /cookies/ would be NTPD asking NTS-KE for the data the
    cookie represents. The only reason to do that would be if NTPD never
    handles key storage / creation / ratcheting / etc itself and
    offloads all of that to NTS-KE.<br>
    <br>
    That is the one option that has been universally shot down as bad.
    I've pushed an update to nts.adoc.<br>
    <br>
    <div class="moz-signature">-- <br>
      <i>"In the end; what separates a Man, from a Slave? Money? Power?
        No. A Man Chooses, a Slave Obeys."</i> -- Andrew Ryan
      <p>
        <i>"Utopia cannot precede the Utopian.
          It will exist the moment we are fit to occupy it."</i> --
        Sophia Lamb
      </p>
      <p>
        I work for the <a href="https://icei.org/">Internet Civil
          Engineering Institute</a>, help us save the Internet from
        Entropy!
      </p>
    </div>
  </body>
</html>