<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I apologize - what I meant was that at least one PFS cipher suite should be mandatory, alongside the existing mandatory <br><br>SP800-52 Rev.1 actually has rules for both now, and for the next couple of years, for instance, lines 547 and 548<br><div dir="ltr" style="font-size: 16px; font-family: serif; left: 350.08px; top: 509.44px; transform: rotate(0deg) scale(0.666667, 1); transform-origin: 0% 0% 0px;" data-angle="0" data-font-name="Times" data-canvas-width="4"><br>Agencies shall develop migration plans to 547 support TLS 1.2 by January 1, 2015.<br><br></div> - 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:<br><br><div dir="ltr" style="font-size: 16px; font-family: serif; left: 266.56px; top: 673.6px; transform: rotate(0deg) scale(0.8896, 1); transform-origin: 0% 0% 0px;" data-angle="0" data-font-name="Times" data-canvas-width="4.448">TLS server implementations shall support the following cipher suites:</div><div dir="ltr" style="font-size: 16px; font-family: serif; left: 168px; top: 693.28px; transform: rotate(0deg) scale(0.906256, 1); transform-origin: 0% 0% 0px;" data-angle="0" data-font-name="Times" data-canvas-width="282.75199999999995">•TLS_RSA_WITH_3DES_EDE_CBC_SHA</div>•TLS_RSA_WITH_AES_128_CBC_SHA<br><br>as opposed to simply remaining on the "should" list indefinitely.<br><br><div>> To: tahoe-dev@tahoe-lafs.org<br>> From: eternaleye@gmail.com<br>> Subject: RE: Dusting off lafs-rpg.<br>> Date: Mon, 25 Nov 2013 17:33:42 -0800<br>> <br>> Garonda Rodian wrote:<br>> <br>> > NIST SP800-52 Rev.1 is also in draft, with community comment requested.<br>> > <br>> > http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201<br>> > <br>> > I'd say they should require PFS, but it's another standards body's<br>> > commentary.<br>> <br>> <snip><br>> <br>> The problem there is that PFS is nowhere near universally supported; any <br>> best-*current*-practices document needs to make a compromise between "This <br>> has some undesirable security properties" and "this will make the service <br>> unreachable."<br>> <br>> To wit, if all browsers refused to connect to non-PFS servers then at <br>> _least_ 54% of sites would fail to function[1], and users would likely see <br>> more due to various fallback scenarios (e.g. it was recently found that <br>> several antivirus programs on Windows act as SSL MITM proxies and force <br>> SSLv3 fallback[2]. Google discovered this due to their force-disabling SSLv3 <br>> fallback for Google sites in Chrome 31, which was a test designed to find <br>> this exact kind of issue).<br>> <br>> Similarly, if all webservers refused to permit connections from non-PFS <br>> browsers, there would be significant issues. For instance, Internet Explorer <br>> only supports the ECDHE key exchange with RC4, and RC4 has known issues[3].<br>> <br>> <br>> [1] https://community.qualys.com/blogs/securitylabs/2013/10/09/ssl-pulse-now-tracking-forward-secrecy-and-rc4<br>> <br>> [2] http://www.ietf.org/mail-archive/web/tls/current/msg10676.html<br>> <br>> [3] https://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attacks<br>> <br>> _______________________________________________<br>> tahoe-dev mailing list<br>> tahoe-dev@tahoe-lafs.org<br>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev<br></div> </div></body>
</html>