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. 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. 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? 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/ [2] 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 [6] 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/ -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
