Dusting off lafs-rpg.

Garonda Rodian deepside at hotmail.com
Wed Nov 27 17:39:31 UTC 2013


I apologize - what I meant was that at least one PFS cipher suite should be mandatory, alongside the existing mandatory 

SP800-52 Rev.1 actually has rules for both now, and for the next couple of years, for instance, lines 547 and 548

Agencies shall develop migration plans to 547 support TLS 1.2 by January 1, 2015.

 - it would be very easy to add a rule stating that by Jan 1, 2015, PFS cipher suite X will be added to the the "shall support" cipher suite list - this is a change to lines 689-692, which are currently:

TLS server implementations shall support the following cipher suites:•TLS_RSA_WITH_3DES_EDE_CBC_SHA•TLS_RSA_WITH_AES_128_CBC_SHA

as opposed to simply remaining on the "should" list indefinitely.

> To: tahoe-dev at tahoe-lafs.org
> From: eternaleye at gmail.com
> Subject: RE: Dusting off lafs-rpg.
> Date: Mon, 25 Nov 2013 17:33:42 -0800
> 
> 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
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20131127/d36a720b/attachment.html>


More information about the tahoe-dev mailing list