On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote: > Gary E. Miller via devel <devel@ntpsec.org>: > > On Sat, 2 Feb 2019 06:16:45 -0500 (EST) > > "Eric S. Raymond via devel" <devel@ntpsec.org> wrote: > > > > > NEVER CONFIGURE WHAT YOU CAN DISCOVER > > > > > > These are from nts.adoc: > > > > > > *tls1.2* Allow TLS1.2 connection. > > > > > > *tls1.3* Allow TLS1.3 connection. > > > > > > We don't need these because in this 'graph > > > > > > Implementations MUST NOT negotiate TLS versions earlier than 1.2, > > > SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and > > > MAY refuse to negotiate any TLS version which has been superseded by a > > > later supported version. > > > > > > the last normative is a MAY, not a MUST. Thus, you never need to do > > > anything but allow some connection at 1.2 or up even once 1.2 is > > > superseded. Correct[racticr is to use the highest version you have. > > > > As previously asked, discussed and answered here: > > > > The list of allowed versions, and even names, will change. Sometimes > > overnight as we have seen many times. > > Of course it will. That is irrelevant to where options to suppress > capabilities are needed, because the right behavior is always "allow > everything above the last version implicated in a crypto emergency"... > > > Being able to force a version is required for testing. > > ...UNLESS you're forcing for testing. That is a valid point. > > But if that were your concern you should have specified a forcetls > option, not these silly allow flags. If you wish to add that to nts.adoc > I will consider it on my to-do list. It can go with mintls. Doesn't > need to be per-peer, obviously.
I really recommend to use a minimum version, and not a list of supported versions. Having a list causes all kinds of problems. > > Oh, and discovery of these is a bitch. > > Nevertheless, that is what we are going to do, because it is the right thing. > > We may not be able to do it before first ship to Cisco, but it must remain > the eventual goal unless it is demonstrated to be > impractical/impossible rather than merely difficult. Users are not likely to change the configuration of every application in case like a protocol or cipher needs to be disabled, they will likely not know which applications all need to be modified. And if they do modify it, most likely some time later that configuration will cause problems. I suggest you stick to the defaults. In case of problems they will be modified by the library maintainers so that they no longer are part of the default. Kurt _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
