Miroslav Lichvar writes: > On Wed, Mar 30, 2016 at 10:57:35AM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > If the server is not able to respond in time (whatever that means), it > > > shouldn't respond at all. The client will try again later. Responding > > > with a plain NTP message would not help as the client would ignore the > > > reply. Even if it didn't ignore it, the new request would have to be > > > the same NTS message as before, because the server doesn't have the > > > previous request. I doubt any server implementation would want to > > > cache requests and replies. > > > > I disagree, but this may need to become a local policy choice. > > > > Are you suggesting the server saves state between the first incoming > > client request that we can't respond to "fast enough" and then on the > > next poll the server sees that the client request is identical, so it > > can immediately respond with the data it has had time to generate? > > Yes, if you really needed to significantly delay the response, this > would be one way do to it without having to modify the NTS spec. But I > still don't see how it's useful and I'd be worried about DoS attacks > it could bring in.
I don't know how to describe this any better. What is the DoS vector you see? The premise is that the crypto calculations "take longer than we want to wait" for something to do in between T2/T3. If these crypto operations take "a relatively long time" we may choose to do them outside the main processing "thread". > > > What restrictions would you like to lose? The suspension of the NTS > > > protocol with plain NTP messages you described seems to me like a > > > major complication in the protocol, which would require the server to > > > cache the client's requests. > > > > As opposed to degrading the server's performance? > > I'm not sure I follow. How is this related to the server's performance? A server cannot do "expensive" operations in-line. This is the thing I don't know how to describe better. I've described it several times from several angles. > > I think we should define as few restrictions as possible here, and leave > > it to the implementation to decide what works best. > > As long as the protocol stays simple and secure, I'm ok with that. OK. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
