<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2019 at 5:57 PM John Gilmore <<a href="mailto:gnu@toad.com">gnu@toad.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is an effort underway to design and standardize improved methods<br>
of securing the NTP time-synchronization protocol.  Here's an overview<br>
of the effort, plus pointers to a published RFC that documents the<br>
requirements that they are trying to satisfy, and to the current<br>
Internet-Draft:<br>
<br>
  <a href="https://www.ietfjournal.org/a-new-security-mechanism-for-the-network-time-protocol/" rel="noreferrer" target="_blank">https://www.ietfjournal.org/a-new-security-mechanism-for-the-network-time-protocol/</a><br>
  <a href="https://www.rfc-editor.org/rfc/rfc7384.txt" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc7384.txt</a><br>
  <a href="http://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp" rel="noreferrer" target="_blank">http://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp</a><br>
<br>
The draft protocol is being implemented now by two or more NTP<br>
implementations to begin interoperation testing.<br>
<br>
There is a long history of half-assed or broken crypto applied to various<br>
iterations of NTP (pre-shared keys, Autokey, etc).  None has yet had that<br>
essential combination of ease of deployment and lack of vulnerability.<br>
<br>
Before this gets standardized and deployed, has anybody on this list<br>
analyzed the threat model and the draft mechanisms to see if they would<br>
actually accomplish the goal of cryptographically securing the<br>
worldwide accurate time distribution overlay network?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Let us step back and ask what the actual security requirements are. I don't think they are quite the same as what secure-NTP would provide.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are three separate issues:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Is the current time after time t1?</div><div class="gmail_default" style="font-size:small">2) Is the current time before t2?</div><div class="gmail_default" style="font-size:small">3) Did event A happen before or after event B?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For purposes of preventing replay attacks, use of expired credentials, etc. it is usually acceptable to have the current time correct to a few hours.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For purposes of timestamping logs, etc, I would normally want the time to be correct to ten seconds or better.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For purposes of performing transaction processing, I don't need time at all to decide if A happened before B, I need a transaction log.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the sort of answers I am looking at are very much more along the lines of 'blockchain without the inefficiency of proof of work, stake, etc.'</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since the time is a subjective quantity, this is an area where some form of trusted party is going to be inevitable but we can use meta-notary type techniques to produce ridiculously high work factors.</div></div></div>