Against certain proposed TLS client-side options

[Kurt Roeckx]

On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel <devel at ntpsec.org>:
> > On Sat,  2 Feb 2019 06:16:45 -0500 (EST)
> > "Eric S. Raymond via devel" <devel at 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