<html><body><p>Hi Drew,<br><br>It seems the minutes for the last meeting have not been merged yet.<br>Here is the PR that has the minutes. <a href="https://github.com/swift-server/work-group/pull/72">https://github.com/swift-server/work-group/pull/72</a><br><br>Regards,<br>Gelareh<br><br><img width="16" height="16" src="cid:1__=8FBB0A5DDFC4025B8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Gelareh Taban via swift-server-dev ---02/20/2017 02:09:26 PM---Hi Drew, Sorry for the delayed respons"><font color="#424282">Gelareh Taban via swift-server-dev ---02/20/2017 02:09:26 PM---Hi Drew, Sorry for the delayed response. I was off for a couple of days enjoying our</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Gelareh Taban via swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Drew Crawford <drew@sealedabstract.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">swift-server-dev@swift.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/20/2017 02:09 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [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 size="4">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 </font><a href="https://github.com/swift-server/work-group/tree/master/meetings/security"><u><font size="4" color="#0000FF">https://github.com/swift-server/work-group/tree/master/meetings/security</font></u></a><font size="4">).<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></font><img src="cid:1__=8FBB0A5DDFC4025B8f9e8a93df938690918c8FB@" width="16" height="16" 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 size="4" 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><font size="4"><br></font><font color="#5F5F5F"><br>From: </font>Drew Crawford via swift-server-dev <swift-server-dev@swift.org><font color="#5F5F5F"><br>To: </font>swift-server-dev@swift.org<font color="#5F5F5F"><br>Date: </font>02/16/2017 06:07 PM<font color="#5F5F5F"><br>Subject: </font>[swift-server-dev] FIPS certification<font color="#5F5F5F"><br>Sent by: </font>swift-server-dev-bounces@swift.org<font size="4"><br></font><hr width="100%" size="2" align="left" noshade><font size="4"><br><br></font><font size="4" face="Helvetica"><br>Not to start a large bikeshed, but I was surprised by the following statement in the README:</font><ul><ul><ul><ul><font size="4" 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></ul></ul><font size="4" face="Helvetica">This is, as I understand it, the sole argument presented for choosing OpenSSL in the Linux implementation.</font><p><font size="4" 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 size="4" face="Helvetica">To provide some (possibly biased) background knowledge for the discussion:</font><p><font size="4" face="Helvetica">* Until recently, the FIPS 140 standard mandated conforming cryptographic libraries make available the DUAL_EC_DRBG cipher with certain unexplained magic numbers.<br>* The New York Times reports that DUAL_EC_DRBG is actually an NSA backdoor based on information they received from Edward Snowden. [2]<br>* 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]<br>* Reuters reports that the NSA paid $10m to a security firm to ensure this backdoored algorithm was the default on various products. [4]<br>* 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]<br>* 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 size="4" color="#0000FF" face="Helvetica">[</font></u></a><font size="4" face="Helvetica">5]<br>* 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]<br>* 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><font size="4"><br></font><font size="4" face="Helvetica"><br>With that background, some questions:</font><font size="4"><br></font><font size="4" face="Helvetica"><br>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?<br>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.<br>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?<br>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.<br>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.<br>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?<br>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?<br>7. Why is OpenSSL preferred to other FIPS-validated libraries such as NSS?</font><font size="4"><br></font><font size="4" face="Helvetica"><br>Thanks in advance for what is hopefully a productive discussion,</font><font size="4"><br></font><font size="4" face="Helvetica"><br>Drew</font><font size="4"><br></font><font size="4" face="Helvetica"><br>[0] </font><a href="http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf"><u><font size="4" color="#0000FF" face="Helvetica">http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf</font></u></a><font size="4" face="Helvetica"><br>[1] </font><a href="http://www.vm.ibm.com/related/tcpip/pm93363.html"><u><font size="4" color="#0000FF" face="Helvetica">http://www.vm.ibm.com/related/tcpip/pm93363.html</font></u></a><font size="4" face="Helvetica"><br>[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 size="4" 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><font size="4" face="Helvetica"><br>[3] </font><a href="https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html"><u><font size="4" color="#0000FF" face="Helvetica">https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html</font></u></a><font size="4" face="Helvetica"><br>[4] </font><a href="http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220"><u><font size="4" color="#0000FF" face="Helvetica">http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220</font></u></a><font size="4" face="Helvetica"><br>[5] </font><a href="http://marc.info/?l=openssl-announce&m=138747119822324&w=2"><u><font size="4" color="#0000FF" face="Helvetica">http://marc.info/?l=openssl-announce&m=138747119822324&w=2</font></u></a><font size="4" face="Helvetica"><br>[6] </font><a href="https://wiki.openwrt.org/doc/howto/benchmark.openssl"><u><font size="4" color="#0000FF" face="Helvetica">https://wiki.openwrt.org/doc/howto/benchmark.openssl</font></u></a><font size="4" face="Helvetica"><br>[7] </font><a href="http://veridicalsystems.com/blog/secure-or-compliant-pick-one/"><u><font size="4" color="#0000FF" face="Helvetica">http://veridicalsystems.com/blog/secure-or-compliant-pick-one/</font></u></a><tt><font size="4">_______________________________________________<br>swift-server-dev mailing list<br>swift-server-dev@swift.org</font></tt><tt><u><font size="4" color="#0000FF"><br></font></u></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><u><font size="4" color="#0000FF">https://lists.swift.org/mailman/listinfo/swift-server-dev</font></u></tt></a><font size="4"><br><br><br></font><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><p><p><BR>
</body></html>