Re: [wpkops] NIST 800-52

[Gary Gapinski <[e-mail]>]

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

I think this is what was mentioned recently –

 

http://dx.doi.org/10.6028/NIST.SP.800-52r1" rel="nofollow">http://dx.doi.org/10.6028/NIST.SP.800-52r1

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" rel="nofollow">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" rel="nofollow">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 https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=33&platform=Win%207" rel="nofollow">Chrome|https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1" rel="nofollow">IE11|https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=27&platform=Win%208" rel="nofollow">Firefox|https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=7&platform=OS%20X%2010.9" rel="nofollow">Safari|https://www.ssllabs.com/ssltest/viewClient.html?name=Android&version=4.4.2" rel="nofollow">Android|https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=7&platform=iOS%207.1" rel="nofollow">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.

1. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
4. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
5. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
6. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
7. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
8. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
9. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
10. TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
11. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
12. TLS_RSA_WITH_AES_128_GCM_SHA256
13. TLS_RSA_WITH_AES_256_GCM_SHA384
14. TLS_RSA_WITH_AES_128_CBC_SHA
15. TLS_RSA_WITH_AES_256_CBC_SHA
16. 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).