<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi Gelareh,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><p>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.</p></blockquote></div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><div><blockquote type="cite" class="clean_bq"><p>3 - This is a topic that was not discussed, but I would not think that it would be on by default.</p></blockquote></div><p>IMO the question becomes: if the default is not to run in FIPS mode, why is the default backend a FIPS-compliant one? If there is a consensus that LibreSSL has better security, performance, and response time, while OpenSSL has better compliance, it seems logical to me that LibreSSL would be the default, with OpenSSL/FIPS available as an option to users concerned about compliance, rather than OpenSSL non-FIPS as default, which neither address compliance concerns nor performance/security concerns.</p></div></div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><p>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.</p></blockquote></div><p>Do you represent such a usecase? Can you tell us about your requirements?</p><p>My concern here is that we are creating the appearance that decisions are being made for the benefit of unknown parties with unknown compliance requirements. I think it would be appropriate if those affected by this issue posted to the list, and explained what their requirements are. 140-1 or 140-2 (or 3 or 4)? Is this coming from inside counsel or is it regulatory? Is the party going to take an active role in benefiting the Swift ecosystem? Is the party unable to afford the four figures to license an actually *good* library such as wolfSSL / MatrixSSL that we could provide a plugin mechanism for? We cannot know the answers to these questions because the part(ies) are not here.</p> <div id="bloop_sign_1487697011873453056" class="bloop_sign"></div><div id="bloop_sign_1487697011873453056" class="bloop_sign">In the spirit of citing actual use cases: We have a technical requirement not to use OpenSSL (libssl), because from their track record we conclude that the TLAs have binders full of exploits, and because it is impractical to use low-level crypto APIs such as OpenSSL correctly [0]. LibreSSL is a bit better and perhaps the exploits fit in a single binder, but as the API is essentially identical it is still impractical to use correctly, so this isn't enough of a delta for us. In our internet-facing TLS stack, we need a high-level approach along the lines of s2n. We are actually running on that in production today, and switching over to even a libssl/LibreSSL stack would be viewed poorly relative to our current practice. So under that hypothetical I would expect our practice to continue.</div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><br></div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;">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. </blockquote></div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><br></div><div id="bloop_sign_1487697011873453056" class="bloop_sign">I would like to see a backend mechanism flexible enough to get our s2n work upstream (as well as hooks for e.g. wolfSSL backends etc.) However, s2n is not at all API-compatible with OpenSSL, so considering a plugin model that is designed around OpenSSL-alikes it wouldn't be a possibility. I think this is not accidental: the breadth of the OpenSSL API [0] and other broad low-level APIs [1] is very quite harmful to security in practice, and so by designing a plugin mechanism with an OpenSSL-alike in mind we are ensuring that users with security as their priority need to camp under a different tent. IMO that is not in the interests of supporting everyone's requirements.</div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><br></div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;"><div id="bloop_sign_1487697011873453056" class="bloop_sign">MongoKitten also does some of its own MD5 checksum hashing. It should really get this from a standard lib - so the “Server APIs” for security shouldn’t just limit itself to TLS but also crypto functionality. </div></blockquote><div><div class="bloop_sign"><br></div></div><div class="bloop_sign">I did not make this meeting to hear the full argument, but my concern here is that exposing low-level crypto APIs to mere mortals is harmful [0]. To take an example from MongoKitten, they appear to be using MD5 to hash passwords [3], which, if I understand correctly, has been deprecated upstream in mongodb in part due to concerns around MD5 [2].</div><div class="bloop_sign"><br></div><div class="bloop_sign">There's actually a second code smell here: for some reason this password is treated with a fast hashing function, instead of a key-derivation function. Perhaps the appropriate security guarantees are made elsewhere in the authentication protocol? But if the hash is merely obfuscatory, why obfuscate at all?</div><div class="bloop_sign"><br></div><div class="bloop_sign">Presumably the answer to these riddles is upstream in mongodb and that project's design choices, entirely out of MongoKitten's hands. But from a Swift APIsurface POV, we have a responsibility to clear the standard API of footguns, rather than to hand them out. I think the record shows that wide availability of low-level crypto APIs leads to designs that are at least questionable, if not actual vulnerabilities, and that many common algorithms (MD2-5) are definitively harmful for us to ship.</div><div class="bloop_sign"><br></div><div class="bloop_sign">It would be better to expose high-level APIs to userspace (e.g. like keyczar or NaCl), and encourage working with crypto at that level of abstraction. Or, if that isn't necessary, to ship nothing. But users unlucky enough to need to choose and securely compose underlying crypto primitives should be capable of BYO, as MongoKitten did here. This is not just me saying this, e.g. [0] [4] [5] [6] [7] etc.</div></div><div id="bloop_sign_1487697011873453056" class="bloop_sign"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><p>7 - NSS has GPL license which is a problem.</p></blockquote></div><p>NSS's license is the MPL, not the GPL. Again it is not clear what party is affected by this, but to cite our usecase, MPL would not be a problem. NSS is not ideal to us for various reasons, but none of them are licensing.</p><p>Drew</p><p>[0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/</p><p>[1] http://faq.sealedabstract.com/dont_use_common_crypto/</p><p>[2] https://jira.mongodb.org/browse/SERVER-6977</p><p>[3] https://github.com/OpenKitten/MongoKitten/blob/63321389439cb3749a3f2648ce2817931408ae0d/Sources/MongoKitten/Auth/Database%2BAuthentication.swift#L176</p><p>[4] https://rdist.root.org/2009/06/10/when-crypto-attacks-slides-posted/</p><p>[5] http://spar.isi.jhu.edu/~mgreen/CryptoAPIs.pdf</p><p>[6] https://courses.csail.mit.edu/6.857/2014/files/18-das-gopal-king-venkatraman-IV-equals-zero-security.pdf</p><p>[7] https://github.com/golang/go/issues/5597</p><p><br></p></div><p class="airmail_on">On February 20, 2017 at 2:07:40 PM, Gelareh Taban (<a href="mailto:gtaban@us.ibm.com">gtaban@us.ibm.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<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:3523FAD2-2ED8-4C65-8A0C-E4DC2E66F1F2" 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></p>
<hr width="100%" size="2" align="left" noshade="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>
<div style="margin-left: 4em"><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></div>
<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>
<p><font face="Helvetica">To provide some (possibly biased)
background knowledge for the discussion:</font></p>
<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></p>
</div></div></span></blockquote></body></html>