On Wed, Mar 23, 2016 at 1:11 PM, Miroslav Lichvar <[email protected]> wrote:
> On Wed, Mar 23, 2016 at 03:59:48AM -0400, Sharon Goldberg wrote: > > * 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. > > This is an interesting idea, but wouldn't the server have to save the > incremental hash between client's requests? An NTP server normally > doesn't keep any state for clients and when it does (e.g. for > monitoring and rate limiting), it's all in a constant amount of memory > to prevent DoS attacks on the server. If an incremental hash is used, then it would require a constant amount of memory on the server. > Clients that would benefit most > from having timestamps authenticated retroactively probably would be the > ones that poll the server least frequently and are most likely to > have their state on the server lost. I'm not sure I understand this point. If a client is querying infrequently, why not just wait until the KE completes, and the key is established, before sending timing messages that can then be authenticated with the established key? Why would you want to start a timing exchange in parallel with the KE? Sharon
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
