On Mon, 28 Mar 2016, Danny Mayer wrote:
We have to be careful here. I agree that at least some cipher suites should be specified as a minimal subset in the draft but we also need flexibility as new ciphers come out and older ones are found to be vunerable. Otherwise we will need to create new RFC's to update the RFC for either of these scenarios.
We should pick a cipher suite. Absent a compelling reason for more, let's just pick one (for now).
And we do need to provide for algorithm agility. Unfortunately, that is much trickier than merely parameterizing ciphers - we also need to understand the negotiation of cipher suites and prevent downgrade attacks. Here's some discussion on the topic: https://tools.ietf.org/html/rfc7696
For good or ill, other negotiations (e.g. NTS version number) may also provide opportunities for downgrade. Which means we may be also to address multiple vulnerabilities at once.
One step toward addressing all of this might be to extend the ntp client config file to include a bit for "this name server is expected to use NTS (version #blah)". Perhaps cipher suite info could be in the same config file or in the server's certs?
Lastly, do not be afraid to roll a new RFC to introduce a new algorithm. While it makes sense to have an IANA registry for cipher suites, "standards action" might be a good choice of policy to add a new entry into that registry.
-- Sam _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
