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