[swift-server-dev] FIPS certification

Tue Feb 21 09:57:03 CST 2017

Hi Drew,

It seems the minutes for the last meeting have not been merged yet.
Here is the PR that has the minutes.
https://github.com/swift-server/work-group/pull/72

Regards,
Gelareh

From:	Gelareh Taban via swift-server-dev <swift-server-dev at swift.org>
To:	Drew Crawford <drew at sealedabstract.com>
Cc:	swift-server-dev at swift.org
Date:	02/20/2017 02:09 PM
Subject:	Re: [swift-server-dev] FIPS certification
Sent by:	swift-server-dev-bounces at swift.org

Hi Drew,

Sorry for the delayed response. I was off for a couple of days enjoying our
30C winter in Austin :-)

Thanks for picking up on the 140 typo - I guess my eyes were error
correcting it! I will fix it.

The points you raise here are definitely ones we have tried to address in
the working group meetings so far (see
https://github.com/swift-server/work-group/tree/master/meetings/security).

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:
- Use case for a server setting
- Flexibility to plug and play library (OpenSSL APIs are largely a superset
of the APIs in LibreSSL)
- Apache Licensing
- Prevalence and support on a large number of platforms

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.

With these in mind, I will try to answer your questions:
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.
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.
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.
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.
4 - You are correct, but this is not on by default, this would impact only
use cases which require FIPS.
5 - As far as know, there are no plans for that right now.
6 - Good question. I think our current architecture can to some extent
address this, but we should talk about this.
7 - NSS has GPL license which is a problem.

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!

I am about to send an email our about the next server security meeting
group which I sincerely hope you will join 😃

Regards,
Gelareh

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 wDrew 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

From: Drew Crawford via swift-server-dev <swift-server-dev at swift.org>
To: swift-server-dev at swift.org
Date: 02/16/2017 06:07 PM
Subject: [swift-server-dev] FIPS certification
Sent by: swift-server-dev-bounces at swift.org

Not to start a large bikeshed, but I was surprised by the following
statement in the README:
            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.

This is, as I understand it, the sole argument presented for choosing
OpenSSL in the Linux implementation.

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].

To provide some (possibly biased) background knowledge for the discussion:

* Until recently, the FIPS 140 standard mandated conforming cryptographic
libraries make available the DUAL_EC_DRBG cipher with certain unexplained
magic numbers.
* The New York Times reports that DUAL_EC_DRBG is actually an NSA backdoor
based on information they received from Edward Snowden. [2]
* 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]
* Reuters reports that the NSA paid $10m to a security firm to ensure this
backdoored algorithm was the default on various products. [4]
* 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]
* 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." [5]
* 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]
* 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]

With that background, some questions:

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?
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.
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?
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.
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.
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?
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?
7. Why is OpenSSL preferred to other FIPS-validated libraries such as NSS?

Thanks in advance for what is hopefully a productive discussion,

Drew

[0] http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[1] http://www.vm.ibm.com/related/tcpip/pm93363.html
[2]
https://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=0

[3] https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
[4]
http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220
[5] http://marc.info/?l=openssl-announce&m=138747119822324&w=2
[6] https://wiki.openwrt.org/doc/howto/benchmark.openssl
[7] http://veridicalsystems.com/blog/secure-or-compliant-pick-one/
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170221/97df7b18/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170221/97df7b18/attachment.gif>