On 7/28/2010 1:13 AM, Mikael Abrahamsson wrote: > On Tue, 27 Jul 2010, Danny Mayer wrote: > >> Because the overhead cost is huge compared to the benefit and you are >> adding a major increase in latency and probably jitter as a result. >> Small and nimble is much better. > > Is this a knee-jerk response or has this actually been investigated with > a 50+ year lifecycle of the protocol in mind? CPUs have gained > AES-cryptography in hardware as of the past few years, the major reasons > (that it's quite an addition to the workload) for not doing it is going > away. >
No, I've been there before. It's not a problem of adding a provision for such things, provided you make the provisioning flexible enough and make sure that the client can safely ignore whatever it doesn't understand. That won't work for encypted packets since it cannot get to the timestamp. That in turns requires that in order to accept encrypted packets you have to require all nodes using them understand the same encryption algorithm AND you need to provide them with keys to decrypt them which is also a provisioning problem. What happens if you want to change keys? Change algorithms? > At least provide extensibility in the protocol so that this can be added > later, especially with the challenges you mention in mind. > >> See above. Also no discussions have been held on how you authenticate >> a server (or for that matter a client if that even has value) so that >> it does not depend on the clocks of each node in the network. > > Then those discussions perhaps should be had. > > If time and frequency is important then it's important enough for it to > be properly authenticated, and if authentication/signing is implemented, > then you've done most of the framework for encryption as well. The framework is one thing but decryption is something else again. Danny _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
