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

From: Dieter Sibold <[email-masked]>
Date: Thu, 24 Mar 2016 18:32:04 +0100

Hello Sharon,
thanks for your review. See comments and questions below.

> Am 23.03.2016 um 08:59 schrieb Sharon Goldberg <[email-masked] <mailto:[email-masked]>>:
> 
> Dear WG,
> 
> Aanchal Malhotra and I reviewed the client/server (unicast) key
> exchange (KE) protocol in the NTS draft (-013). We also discussed
> it with Ran Canetti [1] and Hugo Krawcyzk [2]. As I wrote in an earlier email, we believe NTS's KE can be modified
> to use one public key crypto operation, rather than three.
> 
> We also believe that the protocol can be modified to done in 2
> round trips (4 messages), rather than in 3 round trips (or 6
> messages). The current NTS draft cleverly protects against off-path
> DDoS amplification attacks, using the first round trip. Our
> suggestions would compress the last two round trips into one.  How this is done depends on answers to my questions in my previous email.
> 

Yes, from out point of view this seems to be possible for the current KE. But I’m looking forward to your proposal. Kristof gave an answer to your questions.

> This would help the KE complete faster, so clients could start to
> take authenticated time sooner.
> 
> Also, the WG discussed running client/server timing queries in
> parallel with the NTS KE, so clients can get time fast. (eg running
> iburst in parallel with the NTS KE). We believe that this is
> possible, but from a *security perspective* this must be done
> carefully.
> 

NTS for NTP picky-back all NTS messages on top of NTP packets. Therefore, I don’t see how to run the NTS KE in parallel with NTP without modifying NTP’s specification. This might be different for an implementation that decides to also code an alternative KE (as allowed by Sec. 4.1 in the NTS for NTP specification), e.g. DTLS.

> Why?
> 
> Suppose an unauthenticated timing exchange happens and convince the client to update its clock before KE completes. Then,
> man-in-the-middle can trick the client into updating its clock to a
> bogus time in the past. Then, the attackers inject old compromised
> certificates into the KE exchange. (That is, a revoked/expired
> certificate for which the attacker has learned the secret key
> corresponding to the public key in the certificate.) The client is
> in the past, so it accepts the old bogus certificates, and the
> attacker has defeated any protection provided by NTS. (This is very
> related to the attack by Selvi in [5] and what we wrote about
> attacking SSL certificates in Section III of our paper [6]. See
> also [7].)
> 
> We believe the NTS KE can be modified to authenticate timing
> messages sent in parallel with the KE. Note that this must be done
> *without* requiring these initial timing messages to be MAC'd,
> since before the KE completes, the client and server will not have
> a shared symmetric key.
> 
> We believe that the NTS KE can be modified to include this feature.
> See *. Is this of interest?
> 

But is this not a fundamental problem? Even if an implementation supports an additional KE.  As long as the KE is based on certificates and the verification of the certificate’s validity is based upon time stamps a client which starts  NTS  and has no notion about the current time is a priori vulnerable to attacks described in [5].

> Sharon
> 
> * Roughly, the idea is to compute an incremental hash of all the
> unathenticated timing messages running in parallel with the KE.
> Then, once the KE completes and the client and server share a key,
> this key can be used to MAC this incremental hash. In addition to
> this, we would require the client *not* to update its local clock
> until it has validated this MAC of the incremental hash. In other
> words, the client collects timing samples while the KE is running,
> but updates its clock only after the KE completes. If the KE
> completes in 2 round trips, this might perform reasonably well.
> 
> References
> [1] https://www.cs.bu.edu/fac/canetti/ <https://www.cs.bu.edu/fac/canetti/>
> [2] https://simons.berkeley.edu/people/hugo-krawczyk <https://simons.berkeley.edu/people/hugo-krawczyk>
> [5] https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Jose-Selvi-Breaking-SSL-Using-Time-Synchronisation-Attacks.pdf <https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Jose-Selvi-Breaking-SSL-Using-Time-Synchronisation-Attacks.pdf>
> [6] https://eprint.iacr.org/2015/1020.pdf <https://eprint.iacr.org/2015/1020.pdf>
> [7] http://arstechnica.com/security/2015/10/new-attacks-on-network-time-protocol-can-defeat-https-and-create-chaos/ <http://arstechnica.com/security/2015/10/new-attacks-on-network-time-protocol-can-defeat-https-and-create-chaos/>
> 
> --
> Sharon Goldberg
> Computer Science, Boston University
> http://www.cs.bu.edu/~goldbe <http://www.cs.bu.edu/~goldbe>_______________________________________________
> ntpwg mailing list
> [email-masked] <mailto:[email-masked]>
> http://lists.ntp.org/listinfo/ntpwg <http://lists.ntp.org/listinfo/ntpwg>

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

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Mar 2016 23:20:24 -0700

Kurt Roeckx <[email-masked]> said:
> 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. 

It might be useful for forensics.

That would need appropriate logging.

-- 
These are my opinions.  I hate spam.