Implementing NTS options

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> >>*tls1.2* Allow TLS1.2 connection.
> >>*tls1.3* Allow TLS1.3 connection.
> > Second, why would you ever want one of these allow bits off?  I want to hear
> > a good story here not just to convince me that they're worth the complexity
> > but so it can go in the documentation. 
> 
> >From the draft:
> 
> 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.

I'm not seeing anything in that 'graph which would ever *require* you
to disable down-version TLS.  The last normative is a MAY, not a MUST.

> I assume the default would be no for TLS 1.2 and yes for TLS 1.3
> 
> Should we be specifying min version rather than allowing various versions?

Don't know  I'm news to TLS.

> > Again. The barrier to entry for these is higher because they would need a
> > non-trivial grammar modification
> 
> Does the grammar support quoted strings?

Yes.  That's not the problem. The list construct is the problem.

Accepting a typed token list and properly reflecting it into the
config block layer...it's one of those things that is not conceptually
hard, but is full of corner cases and shtoopidity traps.  Or to put it
another way, there should be a comment near it that says I YAM A DEFECT
ATTRACTOR.

I'd rather deal with conceptually hard, frankly.
-- 
		<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.