Against certain proposed TLS client-side options
Eric S. Raymond
esr at thyrsus.com
Sun Feb 3 01:11:27 UTC 2019
Richard Laager via devel <devel at ntpsec.org>:
> On 2/2/19 4:52 PM, 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:
>
> >> 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"...
>
> It's not that simple. For a real world example...
forcetls is in my to-do list. I intended it to address Gary's concern
about testing, but it would handle the kind of emergency you're describing.
Or am I wrong about that?
--
<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/f947745c/attachment.bin>
More information about the devel
mailing list