Miroslav Lichvar writes: > On Wed, Mar 30, 2016 at 10:32:27PM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > 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? > > Any state that the protocol would require on the server is a potential > vector for a DoS attack. How easy is for an attacker to make new > "connections" and allocate memory on the server?
While great hunks of this are implementation-dependent, I suspect no additional memory will be required to answer "now" as opposed to "later". The difference is "duration" and it's easy enough to deal with that. There are other steps that can be taken, too. > Can the attacker prevent other clients from fully forming the NTS > association? How? > > 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". > > Ok, but why would you not send the result to the client when the > operation is finished? Are you expecting it will take longer than some > minimum expected polling interval of the client (e.g. 1 second)? In a client/server situation, how would you propose to do that before the next poll? What benefit do you gain from doing this? H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
