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

From: Hal Murray <[email-masked]>
Date: Fri, 25 Mar 2016 14:10:40 -0700

[email-masked] said:
>> I'm not sure if it's intentional, but recent versions of ntpd now
>> update the clock with the first (authenticated) sample. Older versions
>> and other implementations may require more.
> I think Danny Mayer told me that was a bug. But I don't know.
> ntpd 4.2.6 needs several samples. 

It's a bug.

Consider what happens if the first response is from a falseticker.  You also 
get a bogus answer if one side of the request/response encounters long 
network delays.

-- 
These are my opinions.  I hate spam.

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Brian Utterback <[email-masked]>
Date: Sat, 26 Mar 2016 21:54:05 -0400

> get a bogus answer if one side of the request/response encounters long

I wonder if it might not make sense to use the first authenticated 
sample to validate the previous unauthenticated samples. If the offset 
from the first authenticated sample is not within some threshold of the 
previous samples then the older ones are thrown out. But if they are 
within the threshold they are accepted.

-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually show their own agendas.
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Hal Murray <[email-masked]>
Date: Sat, 26 Mar 2016 19:24:07 -0700

[email-masked] said:
> I wonder if it might not make sense to use the first authenticated  sample
> to validate the previous unauthenticated samples. If the offset  from the
> first authenticated sample is not within some threshold of the  previous
> samples then the older ones are thrown out. But if they are  within the
> threshold they are accepted. 

My vote would be to put ideas like that on the back burner.

It adds a layer of complexity it two places.  That's an opportunity for bugs.

One is the general NTP timekeeping area.  The other is the security area.

---

From: Sharon Goldberg <[email-masked]>
Date: Sat, 26 Mar 2016 13:25:55 -0400

On Fri, Mar 25, 2016 at 5:10 PM, Hal Murray <[email-masked]> wrote:

> Yes, sounds like a bug.

Sharon

---

From: [email-masked]
Date: Wed, 30 Mar 2016 13:02:19 +0200

>> sample

I second this, with two reasons.

1) I agree with the statement about complexity in two places and am overall unsure whether the outlined idea has a good ratio of benefits to complexity costs.

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.

Kristof

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 31 Mar 2016 19:01:14 +0200

On Thu, Mar 31, 2016 at 12:37:40PM -0400, Sharon Goldberg wrote:
> 
> 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.

I think the point about the local policy is that you might not
have any servers that support NTS, and that you should probably
have a config file that says it should be available or not.

I guess you could have 3 modes of operations:
1) Don't do NTS at all
2) NTS must be supported (by at least some peers)
3) We don't know if NTS is going to be available or not, but we
want to use it if it is.

I'm not sure how useful the 3rd option is.  I currently only see
this working with a config file that doesn't use the pool.  But I
think software should probably have that as default option if it's
using other peers than the pool, at least when NTS is still new.

Kurt

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Mar 2016 11:27:27 -0700

[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.  
Individual documents like NTS should be explicit about what they are 
assuming.  Do they need valid (how close?) time or valid certificates or ???

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?

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Mar 2016 11:34:12 -0700

> 2) NTS must be supported (by at least some peers)

I think that needs to be stronger to be secure.  The "at least some" needs to 
be large enough so that they can't be outvoted by MITM attacks on the rest of 
the servers that client is using.

It gets more complicated if you think about what happens if one of the 
servers with NTS turns into a falseticker.

---

From: Greg Dowd <[email-masked]>
Date: Thu, 31 Mar 2016 18:44:37 +0000

There is already an intrinsic range requirement for ntp to have dates in the last 34 years for the math to work.   Using build date I think sufficed for that.  So there is a finite time range required already which serves as a precedent for defining boundary conditions.  I am in full agreement with those who feel that the apriori assumptions of NTS initialization (e.g., impact of unknown time on cert validation/revocation, requirement to gate time step until "proventic" bit set) should be an output of the NTS design process.  Whether it is in the same document, or a bcp, or whatever, I have no useful info to add.

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Hal Murray
Sent: Thursday, March 31, 2016 11:27 AM
To: NTP Working Group; [email-masked]
Cc: Hal Murray
Subject: Re: [TICTOC] [ntpwg] WGLC on NTS: Round trips for key exchange

EXTERNAL EMAIL

[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
> 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.

It probably deserves a separate document to collect all the ideas.
Individual documents like NTS should be explicit about what they are assuming.  Do they need valid (how close?) time or valid certificates or ???

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.

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Mar 2016 18:12:08 -0700

[email-masked] said:
> I am in full agreement with those who feel that the apriori assumptions of
> NTS initialization (e.g., impact of unknown time on cert validation/
> revocation, requirement to gate time step until "proventic" bit set) should
> be an output of the NTS design process.  Whether it is in the same document,
> or a bcp, or whatever, I have no useful info to add.

I think we should have 2 documents.  NTS should state what assumptions it is 
making about getting started.  I think that is that the system has some 
top-level certificates and that they are valid.

We need another BCP type document to discuss all the techniques, heuristics, 
and issues of getting started when you don't know the time.