Subject: [wpkops] NIST 800-52

From: "Ben Wilson" <[email-masked]>
Date: Tue, 13 May 2014 09:49:50 -0600

I think this is what was mentioned recently - 

http://dx.doi.org/10.6028/NIST.SP.800-52r1

---

From: Gary Gapinski <[email-masked]>
Date: Tue, 13 May 2014 13:26:36 -0400

On 05/13/2014 11:49 AM, Ben Wilson
wrote:

I think this is what was mentioned recently
–

In addition to the excerpts following, I'll note that

§3.2.2 allows each agency to decide on what to do if CRL or
OCSP processing has a problem

§3.4 mandates some extensions

§3.5.1 mandates client certificate validation

the above are recapitulated in §3.9

§4 is overall symmetric with §3

§4.5 allows considerable latitude chasing cross-trusts (such
as tracing a path to a Netherlands CA for one of our certs)

§4.5.1 mandates name constraints and punts to Appendix D

§4.5.4 puts some onus on the user

The only practical way to ensure that servers and clients act in
accordance with these requirements is to field test servers and
clients. I do not expect to have comprehensive specimens available
soon.

These requirements will be non-trivial to implement in our
infrastructure.

Regards,

Gary

PS: I may be wrong about excluding DSS ciphers below

Here's some initial observations excerpted
from several recent emails…

Having requirements
stated multiply and sometimes at odds is not helpful.

§3.1 essentially says TLS 1.1 or 1.2 only for government-only
applications; for citizen or business-facing applications TLS 1.1
shall be used, TLS 1.2 should be used, and SSL 3.0 shall not be
used.

§4.1 says no SSL 3.0 for clients, and that TLS 1.1 shall be
supported, and TLS 1.2 should be supported.

§4.2.2 says revocation checking (via OSCP or CRL) is mandatory.
This essentially means OCSP will be mandatory (and should be
correct), as Mozilla and others are getting out of the CRL
checking business.

§4.3.1 is consonant with §3.3.1.

§4 as well as other parts of the document levy requirements which
will require more effort than has been previously expended. E.g.,
§4.5.2 mandates centralized trust anchor management.

There's a lot more to be discussed at a subsequent time, but
here's my take on ciphers.

I went through §3.3.1 and came up with the following. The last
field on each line is the OpenSSL name for the cipher.

The text is at odds with tables 3-2 and 3-3 (and §3.9.2.3). I
think this is an error in the document.

### SP800-52r1: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf

### TLS
# text shall TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
# text shall TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
# text should TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
# text should TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE-ECDSA-DES-CBC3-SHA
# text should TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE-ECDSA-AES128-SHA
# text should TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE-RSA-DES-CBC3-SHA
# text should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE-RSA-AES128-SHA

### TLS1.2
# text shall TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256
# text should TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384
# text should TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHE-ECDSA-AES128-SHA256
# text should TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
# text should TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384
# text should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
# text should TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256

### Table 3-2 RSA
# 3-2 shall TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA
# 3-2 shall TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
# 3-2 should TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA
# 3-2 should TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE-ECDSA-DES-CBC3-SHA
# 3-2 should TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ECDHE-RSA-DES-CBC3-SHA
# 3-2 should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDHE-RSA-AES128-SHA
# 3-2 may TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDHE-RSA-AES256-SHA

### Table 3-3 TLS 1.2 RSA
# 3-3 shall TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256
# 3-3 should TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384
# 3-3 should TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHE-ECDSA-AES128-SHA256
# 3-3 should TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
# 3-3 may TLS_RSA_WITH_AES_128_CBC_SHA256 AES128-SHA256
# 3-3 may TLS_RSA_WITH_AES_256_CBC_SHA256 AES256-SHA256
# 3-3 may TLS_RSA_WITH_AES_128_CCM ?
# 3-3 may TLS_RSA_WITH_AES_256_CCM ?

### Table 3-4 ECDSA
# 3-4 should TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ECDHE-ECDSA-DES-CBC3-SHA
# 3-4 should TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ECDHE-ECDSA-AES128-SHA
# 3-4 may TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDHE-ECDSA-AES256-SHA

### Table 3-5 TLS 1.2 ECDSA
# 3-5 should TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHE-ECDSA-AES128-SHA256
# 3-5 should TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
# 3-5 should TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384
# 3-5 may TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384

### Table 3-6 DSA
# 3-6 may TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE-DSS-DES-CBC3-SHA
# 3-6 may TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA
# 3-6 may TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-DSS-AES256-SHA

### Table 3-7 TLS 1.2 DSA
# 3-7 may TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE-DSS-AES128-SHA256
# 3-7 may TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE-DSS-AES256-SHA256
# 3-7 may TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE-DSS-AES128-GCM-SHA256
# 3-7 may TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE-DSS-AES256-GCM-SHA384

### Table 3-8 DH
# 3-8 may TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Not implemented.
# 3-8 may TLS_DH_DSS_WITH_AES_128_CBC_SHA DH-DSS-AES128-SHA
# 3-8 may TLS_DH_DSS_WITH_AES_256_CBC_SHA DH-DSS-AES256-SHA

### Table 3-9 TLS 1.2 DH
# 3-9 may TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH-DSS-AES128-SHA256
# 3-9 may TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH-DSS-AES256-SHA256
# 3-9 may TLS_DH_DSS_WITH_AES_128_GCM_SHA256 DH-DSS-AES128-GCM-SHA256
# 3-9 may TLS_DH_DSS_WITH_AES_256_GCM_SHA384 DH-DSS-AES256-GCM-SHA384

### Table 3-10 ECDH
# 3-10 may TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ECDH-ECDSA-DES-CBC3-SHA
# 3-10 may TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA ECDH-ECDSA-AES128-SHA
# 3-10 may TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA ECDH-ECDSA-AES256-SHA

### Table 3-11 TLS 1.2 ECDH
# 3-11 may TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 ECDH-ECDSA-AES128-SHA256
# 3-11 may TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 ECDH-ECDSA-AES256-SHA384
# 3-11 may TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 ECDH-ECDSA-AES128-GCM-SHA256
# 3-11 may TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 ECDH-ECDSA-AES256-GCM-SHA384

### Suite name to OpenSSL name cheat sheet at https://www.openssl.org/docs/apps/ciphers.html

On page 15 is found

The cipher
suites in these tables include the cipher suites that shall
and should be supported (as  described above), and may
be supported. Only cipher suites that are composed of
Approved algorithms are acceptable and are listed in this
section. Cipher suites that do
not appear in this section or Appendix C shall not be
used.

As Appendix C is PSK ciphers those can be ignored. This means that
the only ciphers that can be used are as follows:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DH_DSS_WITH_AES_128_CBC_SHA

TLS_DH_DSS_WITH_AES_128_CBC_SHA256

TLS_DH_DSS_WITH_AES_128_GCM_SHA256

TLS_DH_DSS_WITH_AES_256_CBC_SHA

TLS_DH_DSS_WITH_AES_256_CBC_SHA256

TLS_DH_DSS_WITH_AES_256_GCM_SHA384

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_AES_128_CBC_SHA

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_DSS_WITH_AES_256_CBC_SHA

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_128_CCM

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_RSA_WITH_AES_256_CCM

TLS_RSA_WITH_AES_256_GCM_SHA384

That's the lexicographic order, not any particular order.

Note that there are no TLS_DHE_RSA ciphers. Contrast Chrome|IE11|Firefox|Safari|Android|iOS
ciphers. Those are TLS1.2 capable (most others are not). They of
course handle more than just FIPS and more than SP800-52r1 by
default.

If that set is then restricted to "shall" ciphers and all others
which afford PFS, the result is

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS_DHE_DSS_WITH_AES_128_CBC_SHA

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_DSS_WITH_AES_256_CBC_SHA

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_256_GCM_SHA384

That's the lexicographic order, and can (and will) be tweaked for
a preferred order.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

I placed the non-PFS ciphers last. I ditched the DSS ciphers
entirely.

The Apache HTTP Server config entry for my suggested ciphers is

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA

Java 7 will require a non-default deployment.properties setting to
enable TLS 1.2 (TLS 1.2 is disabled by default on clients). Java 8
uses TLS 1.2 by default. Java 6 lacks TLS 1.2 and thus is
unsuitable for use (as is anything else that cannot do TLS 1.2).

My Thunderbird v24.5.0 appears to be set by default for SSL 3.0
and TLS 1.0  (security.tls.version.min;0,
security.tls.version.max;1) — I'll start testing in a TLS 1.(2|1)
environment. All the ciphers (and I'm unsure all are represented)
must be individually tweaked.

Per SP 800-52r1, all services and clients will require explicit
TLS 1.2 preference, cipher suite restriction, SSL 3.0 exclusion,
certificate validation via OCSP (as CRL support is waning and will
be troublesome after the Heartbleed revocapocalypse), trust anchor
grooming, FIPS 140 validation, and more. This is normative at this
time; the 2015-01-01 date is a deadline for a TLS 1.2 adoption
plan (not TLS 1.2 mandatory as mentioned here and elsewhere).