On 2/2/19 4:52 PM, Eric S. Raymond via devel wrote: > Gary E. Miller via devel <devel@ntpsec.org>: >> On Sat, 2 Feb 2019 06:16:45 -0500 (EST) >> "Eric S. Raymond via devel" <devel@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
