<html><body><p>Hi Drew,<br><br>Sorry for the delayed response. I was off for a couple of days enjoying our 30C winter in Austin :-)<br><br>Thanks for picking up on the 140 typo - I guess my eyes were error correcting it! I will fix it.<br><br>The points you raise here are definitely ones we have tried to address in the working group meetings so far (see <a href="https://github.com/swift-server/work-group/tree/master/meetings/security">https://github.com/swift-server/work-group/tree/master/meetings/security</a>).<br><br>The various shortcoming of OpenSSL regarding security and performance were acknowledged but we think there is still good arguments to be made for going with it and in particular an architecture that can take advantage of OpenSSL code (which has compliance) and LibreSSL code (which improves security, performance and response time). Our main concerns were:<br>- Use case for a server setting<br>- Flexibility to plug and play library (OpenSSL APIs are largely a superset of the APIs in LibreSSL)<br>- Apache Licensing<br>- Prevalence and support on a large number of platforms<br><br>I think a lot of the points you raise can be addressed by our plug-n-play architecture that we are interested in. LibreSSL has cleaned up a lot of the extra code and bad defaults, and has improved performance of OpenSSL. This was done whilst reusing a lot of APIs of OpenSSL. Our current goal is to create an interface such that, if desired, (with minimal work) it is possible to plug in LibreSSL instead of OpenSSL. <br><br>With these in mind, I will try to answer your questions:<br>0 - Yes, there are already use cases which require compliance. Server applications, in enterprise or government settings, do require higher compliance levels. We would like to have a solution where enterprise and non-enterprise communities do not diverge since we can definitely benefit from what each sector brings. <br>1 - Validation is really done for a compliance point of view. It does address certain engineering methodologies, but it does not necessarily detect bugs. That is unarguable.<br>2 - Having the flexibility to plug in different security libraries such as OpenSSL and LibreSSL I believe makes our present scenario workable and practical. Of course if we get to the point where we see that is not doable, or that this is not acceptable and there is enough community support, this needs to be addressed. I am with you.<br>3 - This is a topic that was not discussed, but I would not think that it would be on by default. You are right that a large number of users this is not even a consideration. However for it to be even considered for a lot of enterprise and government settings, this option must exist.<br>4 - You are correct, but this is not on by default, this would impact only use cases which require FIPS.<br>5 - As far as know, there are no plans for that right now. <br>6 - Good question. I think our current architecture can to some extent address this, but we should talk about this.<br>7 - NSS has GPL license which is a problem. <br><br>I would really like to have Swift go along a good path for the community and not just a subsection of the community. I am personally really glad you wrote this because I share a lot of your concerns. To have Swift be successful in the server space, we need to make sure that it can handle the server use cases. Hence, the solution that we have come up with right now. If you have alternate ideas or extension, please share!<br><br>I am about to send an email our about the next server security meeting group which I sincerely hope you will join 😃<br><br>Regards,<br>Gelareh<br><br><br><img width="16" height="16" src="cid:1__=8FBB0A5EDFFF57FE8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Drew Crawford via swift-server-dev ---02/16/2017 06:07:23 PM---Not to start a large bikeshed, but I w"><font color="#424282">Drew Crawford via swift-server-dev ---02/16/2017 06:07:23 PM---Not to start a large bikeshed, but I was surprised by the following statement in the README: A final</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Drew Crawford via swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">swift-server-dev@swift.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/16/2017 06:07 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[swift-server-dev] FIPS certification</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">swift-server-dev-bounces@swift.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font face="Helvetica">Not to start a large bikeshed, but I was surprised by the following statement in the README:</font><br>
<ul><ul><font face="Helvetica">A final motivation in using native libraries is that vendors often go through security certification processes for their own modules and therefore users can get this certification for free. In particular, many use cases that involve government or enterprise data or users, require FIPS 104 compliance or validation. FIPS is a US Government (NIST) cryptographic standard and is a requirement by most government agencies and many enterprises. The process of getting certified is hard, expensive and time consuming and is only done by vendors and large organizations.</font></ul></ul><font face="Helvetica">This is, as I understand it, the sole argument presented for choosing OpenSSL in the Linux implementation.</font><p><font face="Helvetica">First, a clarifying question: are the references to "FIPS 104" in this document actually "FIPS 140"? [0] I am not aware of a "FIPS 104", and google suggests it is a typo [1].</font><p><font face="Helvetica">To provide some (possibly biased) background knowledge for the discussion:</font><p><font face="Helvetica">* Until recently, the FIPS 140 standard mandated conforming cryptographic libraries make available the DUAL_EC_DRBG cipher with certain unexplained magic numbers.</font><br><font face="Helvetica">* The New York Times reports that DUAL_EC_DRBG is actually an NSA backdoor based on information they received from Edward Snowden. [2]</font><br><font face="Helvetica">* While NIST did not remove this algorithm from FIPS 140 until 2014, the backdoor was widely suspected among security experts as early as 2007. [3]</font><br><font face="Helvetica">* Reuters reports that the NSA paid $10m to a security firm to ensure this backdoored algorithm was the default on various products. [4]</font><br><font face="Helvetica">* Separately, OpenSSL's implementation and testing of this algorithm is so poor that it did not even work, accidentally "prevent[ing] all use of the Dual EC DRBG algorithm" [5]</font><br><font face="Helvetica">* The "hard, expensive, and time consuming" FIPS validation process never discovered this bug. Upstream says "Not only the original validation (#1747) but many subsequent validations and platforms have successfully passed the [FIPS] algorithm tests several hundred times now. That's a lot of fail... Frankly the FIPS 140-2 validation testing isn't very useful for catching 'real world' problems." </font><a href="http://marc.info/?l=openssl-announce&m=138747119822324&w=2#5"><u><font color="#0000FF" face="Helvetica">[</font></u></a><font face="Helvetica">5]</font><br><font face="Helvetica">* Because of the enormous expense of re-verifying a one-line patch, OpenSSL did not fix this bug, in part because the FIPS "process forbids modifications of any kind (even to address severe vulnerabilities) without the substantial time and expense of formal retesting and review" [5]</font><br><font face="Helvetica">* Stephen Marquess, OpenSSL maintainer, who implemented some of the FIPS code in question, is "on record as stating that FIPS 140-2 validated software is necessarily less secure than its equivalent unvalidated implementation" [7]</font><br><br><font face="Helvetica">With that background, some questions:</font><br><br><font face="Helvetica">0. Can we name any specific Swift users with FIPS requirements? Are those users incapable of taking the their own steps to address their requirements?</font><br><font face="Helvetica">1. Regardless of what enterprises require, does anyone believe that FIPS 140 or NIST standards in general actually improve security, or is less than actively harmful? That argument is conspicuously absent from a security proposal.</font><br><font face="Helvetica">2. If there were some "certification X" that was required by enterprises but was known to introduce security vulnerabilities for long periods, how bad would things have to be before we told those enterprises to take a hike, and how is that hypothetical distinct from the present situation?</font><br><font face="Helvetica">3. Will Swift use OpenSSL in "FIPS mode" (FIPS_mode_set) ? By default? As an option? At all? What percentage of users do we expect to actually use the FIPS module? I am of the impression the vast majority of even OpenSSL users do not use FIPS.</font><br><font face="Helvetica">4. Have we considered the performance impact of FIPS? According to various benchmarks [6], OpenSSL in FIPS mode is several orders of magnitude slower than otherwise across effectively all workloads.</font><br><font face="Helvetica">5. Is Swift or related projects themselves seeking FIPS certification? What is Swift's policy with respect to exposing "mandated" algorithms to userspace if they are widely expected to contain backdoors or vulnerabilities?</font><br><font face="Helvetica">6. What is Swift's policy with respect to responding to vulnerabilities in dependent FIPS-certified modules, when that code cannot be changed without losing the FIPS certification?</font><br><font face="Helvetica">7. Why is OpenSSL preferred to other FIPS-validated libraries such as NSS?</font><br><br><font face="Helvetica">Thanks in advance for what is hopefully a productive discussion,</font><br><br><font face="Helvetica">Drew</font><br><br><font face="Helvetica">[0] </font><a href="http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf"><u><font color="#0000FF" face="Helvetica">http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf</font></u></a><br><font face="Helvetica">[1] </font><a href="http://www.vm.ibm.com/related/tcpip/pm93363.html"><u><font color="#0000FF" face="Helvetica">http://www.vm.ibm.com/related/tcpip/pm93363.html</font></u></a><br><font face="Helvetica">[2] </font><a href="https://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=0"><u><font color="#0000FF" face="Helvetica">https://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=0</font></u></a><br><font face="Helvetica">[3] </font><a href="https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html"><u><font color="#0000FF" face="Helvetica">https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html</font></u></a><br><font face="Helvetica">[4] </font><a href="http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220"><u><font color="#0000FF" face="Helvetica">http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220</font></u></a><br><font face="Helvetica">[5] </font><a href="http://marc.info/?l=openssl-announce&m=138747119822324&w=2"><u><font color="#0000FF" face="Helvetica">http://marc.info/?l=openssl-announce&m=138747119822324&w=2</font></u></a><br><font face="Helvetica">[6] </font><a href="https://wiki.openwrt.org/doc/howto/benchmark.openssl"><u><font color="#0000FF" face="Helvetica">https://wiki.openwrt.org/doc/howto/benchmark.openssl</font></u></a><br><font face="Helvetica">[7] </font><a href="http://veridicalsystems.com/blog/secure-or-compliant-pick-one/"><u><font color="#0000FF" face="Helvetica">http://veridicalsystems.com/blog/secure-or-compliant-pick-one/</font></u></a><tt>_______________________________________________<br>swift-server-dev mailing list<br>swift-server-dev@swift.org<br></tt><tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></tt><tt><br></tt><br><br><BR>
</body></html>