Subject: Re: [ntpwg] [TICTOC] WGLC on NTS: Round trips for key exchange

From: [email-masked]
Date: Fri, 1 Apr 2016 14:11:39 +0200

> Von: Hal Murray <[email-masked]>
> An: NTP Working Group <[email-masked]>, [email-masked]
> Kopie: Hal Murray <[email-masked]>
> Datum: 31.03.2016 20:27
> Betreff: Re: [TICTOC] [ntpwg]  WGLC on NTS: Round trips for key exchange
> Gesendet von: "TICTOC" <[email-masked]>
> 
> 
> [email-masked] said:
> > I suggest that NTS should encourage users to write the current time to 
a
> > persistent file that is available upon reboot.  This should be 
overwritten
> > on every clock update.    Then, when the client reboots, it can check 
that
> > the expiry time of the certificates is no earlier than the last time 
time
> > written to the presisent file.  This limits the impact of attackers 
that use
> > old compromised certificates to break the security of NTS. 
> 
> I think the issue of getting started is much more complicated than that.
> 
> It probably deserves a separate document to collect all the ideas.

I agree.

> Individual documents like NTS should be explicit about what they are 
> assuming.  Do they need valid (how close?) time or valid certificates or 
???

I can see that a paragraph like this might be necessary. We will think 
about where it's appropriate (NTS main document or NTS-4-NTP).
 
> The above paragraph assumes the system has a writable file system.  The 
> "every clock update" may be too expensive for some systems.
> 
> What happens the first time?  Even if you assume that file was sanely 
> initialized at the factory, the unit may have sat on a shelf for a long 
time.
> 
> What do you do if your clock gets set far into the future?
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Thu, 31 Mar 2016 12:37:40 -0400

On Wed, Mar 30, 2016 at 7:02 AM, <[email-masked]> wrote:

> 2) I am fairly certain that any ideas like this should not concern either
> of the NTS-related documents. Whether/how to use any samples whose
> authenticity & integrity can *not* be verified by NTS should be out of
> scope for us.
>
> I disagree. The whole purpose of NTS is to protect timing information, so
at the very least the document should clearly and precisely explain the
bootstrapping problem (what to do if the client has no idea what time it is
upon startup) and the implications of using unauthenticate time.  Punting
on this means that the draft ignores a central issue in secure time
synchronization.

The language in Section 9.2 of the current draft could be strengthened.

Re:bootstrapping:

I suggest that NTS should encourage users to write the current time to a
persistent file that is available upon reboot.  This should be overwritten
on every clock update.    Then, when the client reboots, it can check that
the expiry time of the certificates is no earlier than the last time time
written to the presisent file.  This limits the impact of attackers that
use old compromised certificates to break the security of NTS.

Re: using unauthenticated time samples.

Leaving this out of scope gives uses just enough rope to hang themselves.
The draft should explain the risks and implication of using unathenticated
time. As I discussed in my previous email, doing this allows even a
*boosttrapped* client to be attacked.  I would even suggest that the draft
use MUST to forbid the use of unauthenticated samples.  If this is already
in the draft and I have missed it, please accept my apologies.

Thanks,
Sharon

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Thu, 31 Mar 2016 16:43:53 -0400

I agree with Hal that this problem is quite complicated. My suggestion was
just meant to deal with a very easy case.

On Thursday, March 31, 2016, Hal Murray <[email-masked]> wrote:

>
> [email-masked] <javascript:;> said:
> use
> [email-masked] <javascript:;>