Against certain proposed TLS client-side options

[Richard Laager]

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

It's 2011. At this point, RC4 is very old. Everyone or almost everyone
is using something better. You might have even disabled RC4, figuring it
was unnecessary (albeit not broken).

Then the BEAST vulnerability happens. Suddenly, RC4 is the only widely
supported TLS 1.0 algorithm that is not vulnerable. Since you still have
real-world clients using TLS 1.0 (at this point in time), you need RC4.
So you disable all the _newer_ algorithms and, if you had previously
disabled it, re-enable RC4.

https://blog.qualys.com/ssllabs/2011/10/17/mitigating-the-beast-attack-on-tls

RC4 made a massive comeback, accounting for some huge percentage of
Internet SSL traffic shortly thereafter.

Client developers implement 1/n-1 record splitting to mitigate BEAST,
and TLS 1.2 is the long term solution.

Now it's 2013, and (oh no!), RC4 is way weaker than we thought. But TLS
1.2 support is still not widely-enough deployed that we can require it.
We can deploy some work-arounds, and ultimately we have to decide which
vulnerability is worse.

https://blog.qualys.com/ssllabs/2013/03/19/rc4-in-tls-is-broken-now-what

Now it's 2015, and the PCI DSS standards set a deadline of June 2016 for
requiring TLS 1.2. Sysadmins collectively shake their heads because
that's still not reasonable given the client install base. Ultimately,
the deadline is pushed to June 2018.

June 2018 comes and we're now all on TLS 1.2 as the minimum, and this is
all behind us.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/25d54f6f/attachment.bin>