On Wed, Mar 30, 2016 at 7:02 AM, <[email protected]> wrote: > 2) I am fairly certain that any ideas like this should not concern either > of the NTS-related documents. Whether/how to use any samples whose > authenticity & integrity can *not* be verified by NTS should be out of > scope for us. > > I disagree. The whole purpose of NTS is to protect timing information, so at the very least the document should clearly and precisely explain the bootstrapping problem (what to do if the client has no idea what time it is upon startup) and the implications of using unauthenticate time. Punting on this means that the draft ignores a central issue in secure time synchronization.
The language in Section 9.2 of the current draft could be strengthened. Re:bootstrapping: I suggest that NTS should encourage users to write the current time to a persistent file that is available upon reboot. This should be overwritten on every clock update. Then, when the client reboots, it can check that the expiry time of the certificates is no earlier than the last time time written to the presisent file. This limits the impact of attackers that use old compromised certificates to break the security of NTS. Re: using unauthenticated time samples. Leaving this out of scope gives uses just enough rope to hang themselves. The draft should explain the risks and implication of using unathenticated time. As I discussed in my previous email, doing this allows even a *boosttrapped* client to be attacked. I would even suggest that the draft use MUST to forbid the use of unauthenticated samples. If this is already in the draft and I have missed it, please accept my apologies. Thanks, Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
