> Am 24.03.2016 um 21:05 schrieb Sharon Goldberg <[email protected]>: > > > > On Thu, Mar 24, 2016 at 4:49 AM, Miroslav Lichvar <[email protected] > <mailto:[email protected]>> wrote: > On Wed, Mar 23, 2016 at 06:17:33PM -0400, Sharon Goldberg wrote: > > Before I say how to get around it, I was wondering why this bothers us so > > much? The current ntpd already has the server saves per-client state, for > > poll interval, rate limiting, and symmetric keys. > > And especially if this state only lives for the duration of the KE? > > There is no limit on the duration. The client may be polling the > server just couple times a day. > > Sorry, I'm confused. The NTS key exchange is a 6-message exchange that > should happen "atomically" (ie. the server gets the clients KE msg, processes > it, and immediately sends its own message. & vice versa: the client gets the > servers KE msg, processes it, and immediately sends its own message. ) > > If we are discussing state that only lives for the *duration of the KE* why > does it matter how often the client polls the server? > > Let's not forget the key exchange will > happen not only when the client is started, but also when the server > refreshes its seed. We certainly don't want clients to drop to their > minimum polling intervals or start a burst when that happens. > > That's interesting point, but could you clarify why that would happen? Why > would clients react in this way? >
When the server refreshes his seed the client has to get its cookie. This is assumed to be done via a cookie exchange — one the last of the rounds of the KE. Therefore the client don’t need to reduce its polling interval. It will only miss one authenticated time exchange. > > Not sure, not an expert on NTP's timing algos. But we have seen that upon > > initalization, ntpd requires about 4 timing samples before it updates its > > clock. So it could collect these timing samples while the NTS KE is running. > > 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. > > > > There is also a question whether the client would really want to use > > > any samples from the non-timing NTS exchanges as the packets are > > > longer and asymmetric, creating an extra error in the measurements. > > > > > > > > So, in my mind, the timing messages would be sent in separate packets from > > the NTS KE messages. They would be sent in parallel. That way, the crypto > > done in NTS does not mess up the accuracy of the timing exchanges. > > If there were two associations per client, I think it would be even > more complex. There would have to be some mechanism for the server to > identify and link the two client associations, so it can hash the > right timestamps (and not timestamps for some other client behind NAT > for instance).The client would have to make sure requests from the > two associations are not too close to each other to not violate the > minimum request interval on the server. > > Yes, that's true. This whole thing adds additional complexity. > So we should be sure it is needed before adding it! > > If the client is > allowed to increase its polling rate, I think it would be more useful > to do that with the NTS association rather than adding an extra > association, so the client would get the first authenticated sample > sooner. > > I'm sorry I don't understand this last point, can you clarify? > > Sharon > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > <http://www.cs.bu.edu/~goldbe>_______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
