Against certain proposed TLS client-side options

[Eric S. Raymond]

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.

> 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.

This is my foot coming down again. I will ignore attempts to argue this issue
further as completely unproductive and a distraction from getting to first
ship.

It's up to you whether you choose to be helpful with this part.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/788f5ff9/attachment.bin>