Replies inline, paragraphs reordered. On 8/31/17, Miroslav Lichvar <[email protected]> wrote:
> As I said before [1], the main issue for me is the use of DTLS transport > in the symmetric mode. It's an easy solution how to get around some > issues, but it demotes the mode to a second-class status. I think all > timing messages in NTP should use the same transport. i.e. standard > NTP format with optional extension fields on UDP port 123. I strongly disagree with you that this is giving "second-class status". I don't view NTS-KE as the Right Thing and DTLS encapsulation as a kludge; if anything, it's the other way around. The DTLS record layer is simple, correct, and performant. It's what I'd want to use for everything if it weren't for the pesky state-management issue. Lots of people on this list seem to have the intuition that sending time packets over DTLS can never be as accurate as sending them over the NTP port with an authenticator attached. But as I showed in my analysis the other day, that just ain't so. > My recommendation is to remove the specification of NTS in the symmetric > mode from the document, at least for now. I believe the NTS-KE used in > the client/server mode can be adopted for the symmetric mode, possibly > with some small extensions, but it will take time. I think most of us > here will agree it shouldn't delay the adoption of NTS in the > client/server mode. If specification for symmetric mode were removed, how would section 4 read? Do you want to get rid of DTLS encapsulation altogether? Restrict what traffic can be sent over it? Can you send a PR with what you have in mind? (Won't promise to merge it, but I'll review it) > The draft is still not clear on how should two active peers match > their DTLS connections. I think it would need to specify the port of > the DTLS client or exchange some additional information in DTLS or NTP > that would identify the peer. In my composing this reply you've convinced me on the "not clear" part; I'd better add something about this in the security considerations or everybody is going to screw it up. With plain unauthenticated NTP, we rely on IP and port to identify peers. But IP addresses aren't cryptographic identities; that's why DTLS needs certificates. To do symmetric mode safely, you need a mutually authenticated handshake (i.e., both sides present certificates). The identity in that certificate is the additional information you're looking for. Chairs, I'm temporarily changing my *own* vote on advancement to "no" until I've expanded on this. It goes back to "yes" with my next git push :-). _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
