Dusting off lafs-rpg.
Alex Elsayed
eternaleye at gmail.com
Tue Nov 26 01:33:42 UTC 2013
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
More information about the tahoe-dev
mailing list