Garonda Rodian wrote: > NIST SP800-52 Rev.1 is also in draft, with community comment requested. > > http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201 > > I'd say they should require PFS, but it's another standards body's > commentary.
<snip> The problem there is that PFS is nowhere near universally supported; any best-*current*-practices document needs to make a compromise between "This has some undesirable security properties" and "this will make the service unreachable." To wit, if all browsers refused to connect to non-PFS servers then at _least_ 54% of sites would fail to function[1], and users would likely see more due to various fallback scenarios (e.g. it was recently found that several antivirus programs on Windows act as SSL MITM proxies and force SSLv3 fallback[2]. Google discovered this due to their force-disabling SSLv3 fallback for Google sites in Chrome 31, which was a test designed to find this exact kind of issue). Similarly, if all webservers refused to permit connections from non-PFS browsers, there would be significant issues. For instance, Internet Explorer only supports the ECDHE key exchange with RC4, and RC4 has known issues[3]. [1] https://community.qualys.com/blogs/securitylabs/2013/10/09/ssl-pulse-now-tracking-forward-secrecy-and-rc4 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html [3] https://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attacks _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
