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