Richard Laager <rlaa...@wiktel.com>: > On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote: > > What I *am* clear on is that we have a job to do to convince Cisco to > > keep funding us. I want to impress them with quality and *speed* and that > > means I am not going to go on any yak-shaving expeditions and you > > shouldn't either. > > Avoiding yak-shaving is one thing. Ignoring the experience of people > with actual operational experience in TLS protocols is another.
That wasn't responding to an argument about TLS, but about the
way NTP implements configuration parsing. Gary thinks - not entirely
without reason - that it's done wrong. But tearing down the grammar
to rebuild it along the lines he likes would be a yak shave.
> > Are you seriously telling me that, for example, the TLS RFCs require me to
> > have a switch in configuration that says "Don't accept TLS 1.3 connections?"
> > If that is true, I want to see a chapter and verse cite.
>
> The TLS RFCs obviously do not require this, but various other standards
^^^^^^^^^^^^^^^
> do (including some that are very much binding).
I'll take that as a "no", then. Or at least "not before first ship".
> > I want to know why it's not fully conformant to always accept 1.2 *and*
> > 1.3 connections and ditch the restrictive options.
>
> In short, because at some point in the future, some binding standard
> will require me to disable TLS 1.2 on my existing production systems and
> I will not be willing (or depending on timing able) to wait for a new
> version of ntpd to ship from upstream and then through my distro.
Ah, OK, a mintls option is already on my to-do list.
--
<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.
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
