Danny I could see that if the *only* channel he has for data is encrypted then it would make sense to also send the timing encrypted. However it is not clear that this is the only channel available since there usually needs to be one in the clear to run the key exchange.
There is an inconsistency between the introduction which says that the service needs to be MITM resilient and section 3.2 which says that packet markers are a problem because of MITM. However I agree that timing packets have resilience that data packets do not have and maybe it would be useful if someone wrote a draft explaining this or pointing to material explaining this so that the parameters and usefulness of any protection scheme could be evaluated. Stewart On 07/03/2012 12:56, Danny Mayer wrote:
I have already said this before and I will repeat this for the purposes of feedback. Time packets do not need to be encrypted as not only do they not contain anything secret, even if you knew the contents they are useless anytime after the packet has been delivered. You do yourself a disfavor in encrypting something that is not worth encrypting. It takes processing overhead, increases packet size, and there is no gain in doing so. You need to justify encrypting something and please don't say that it is because some other document says to encrypt everything. I want to know what is the benefit from doing so, what are the risks in not doing so and what is the cost of doing so, particularly in loss of accuracy, increased error budget, etc. The whole thing is a bad idea from what I can tell. Danny On 3/6/2012 10:35 PM, Cui Yang wrote:Hi, all, I have posted a new draft that discusses the practical solutions for encrypted synchronization protocols. Since we have discussed a lot on this problem, and the security requirement of synchronization also noted that confidentiality may need protection, especially in case that the confidentiality protection is mandatory. Synchronization should be available when the traffic is encrypted. The influences by the encryption are explained, and several possible solutions have been discussed. The URL is below, please review and comment. Title : Practical solutions for encrypted synchronization protocol Author(s) : Y. Cui, M. Bhatia, D. Zhang Filename : draft-cui-tictoc-encrypted-synchronization-00.txt Pages : 10 Date : Mar. 1, 2012 This informational document analyzes the accuracy issues with time synchronization protocols when time synchronization packets are encrypted during transmission. In addition, several candidate solutions on such issues are introduced. A URL for this Internet-Draft is: http://datatracker.ietf.org/doc/draft-cui-tictoc-encrypted-synchronization Thanks, Yang ================== Yang Cui, Ph.D. Huawei Technologies [email protected]_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
-- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
