Great document! Severely needed by the community! Cheers, John
My comments: [General] The document is very TLS focused. The title is "Recommendations for Secure Use of TLS and DTLS" but e.g. "Protocol Versions" does not even mention DTLS! This clearly needs to be fixed. You should differentiate TLS and DTLS in the document. Right now "TLS" often means "TLS and SDTLS". Suggestions: 1. Write "(D)TLS" 2. Write "TLS and DTLS" 3. Define early in the document that "TLS" means "TLS and DTLS” [Section 1] "and will very likely obsolete this document." I don't agree with this. While TLS 1.3 likely mitigates many of the problems, this document applies also to older versions of TLS as well as DTLS. Furthermore the document gives recommendations about key lengths which have very little with TLS 1.3 to do. [Section 1] "implementatios" -> "implementations" [Section 3.1] "it can be assumed that support for the latest version of TLS is recommended" Recommended is weaker that the MUST for supporting TLS 1.2. Change to: "it can be assumed that the BCP is that implementations MUST support, and prefer to negotiate the latest version of TLS" [Section 3.2] https://www.trustworthyinternet.org/ssl-pulse/ says that 99.3 % of all web servers support TLS 1.0, so if this is correct, no more that 0.7 % of servers or SSLv3 only. But this is only a motivation for clients. This document should apply to servers as well as clients. How many clients support SSLv3 only? [Section 3.4] While "MUST NOT" use NULL cipher is clearly correct for browser HTTPS, there are applications cases were NULL is chosen after the requirements are determined to be integrity protection but not encryption. E.g. when the content is already encrypted on the application layer. At a minimum, change "thus are completely insecure" to "thus does not provide confidentiality and must therefore not be used to transfer privacy sensitive data" [Section 3.4] "Implementations MUST NOT negotiate cipher suites offering only so- called "export-level" encryption (including algorithms with 40 bits or 56 bits of security)." "Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security" I think the specific cipher suites need to be explicitly stated. While the UTA group knows the security strength of various ciphers (e.g. DES), most people do not. [Section 3.4] What about the IDEA cipher? [Section 3.4] The section only handles the encryption algorithm. Should also say something about MD5 ciphersuites. [Section 3.4] "accoring" -> "according" [Section 3.4] I think the BCP should specify TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as MUST implement (but not use). [Section 3.4] "A future version of this document might recommend cipher suites for earlier versions of TLS." Not recommending what to use when falling back to TLS 1.1 / 1.0 severely limits the value of this BCP. I think this should be done. [Section 3.5] This section is a little confusing and missing information. It mixes DH, DSS and RSA as well as their use in ciphersuites and certificates. It misses recommendations for EC. Is misses "SHOULD NOT/ MUST NOT for weak keys and signature algorithms". I think the section should be clarified and then include the list of BCP. e.g. SHOULD use SHA-256 or stronger SHOULD NOT use SHA-1 MUST NOT use MD2, MD5 SHOULD use at least 2048 bit RSA, DH, DSS keys SHOULD NOT use 1024, 1536 bit RSA, DH, DSS keys MUST NOT use less than 1024 bit RSA, DH, DSS keys SHOULD use at least 256 bit EC MUST NOT use less than 224 bit EC. [Section 4.2] "including its complexity" What kind of complexity? [Section 4.2] "Diffie Hellman" -> "Diffie-Hellman" [Section 4.2] The list is strange as 1 is general, while 2 and 3 points out a specific cipher suite. I don't think this kind of simple priority ordering can be done. This current order means that: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA is preferred over 4096 bit TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 1024 bit TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 is preferred over TLS_RSA_WITH_AES_128_GCM_SHA256 The first is just wrong, and the second is highly questionable as 80-bit security is REALLY bad. ECRYPT estimates (and this may be the most ambitious estimate done) the security level of 1024 bit to a LOUSY 73 bit (http://www.ecrypt.eu.org/documents/D.SPA.20.pdf) While the server compromise is a risk that may happen, processing power to break 1024 RSA is certain to happen.... I do not think 1024-bit asymmetric crypto has any place in a section saying "we recommend using" [Section 6.1] Section title is "AES-GCM" and then the text refer to general TLS 1.2 considerations. "General" or "TLS 1.2" would be a better titles [Section 6.2] What is an "attack against DLP"? DLP is a mathematical problem without any promised security level... Maybe something like "No efficient general method for solving DLP is known, so DH protect against attackers if sufficiently large parameters are chosen. [Section 6.2] "We thus advocate strict use of PFS-only ciphers." This should be agreement with section 3.4 and I do no think 3.4 lives up to "strict" or "-only". I suggest "We thus strongly advocate use of PFS ciphers." [Section 6.3] "atacker" -> "attacker" "Prorocol" -> "Protocol" JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics Ericsson IETF Security Coordinator Senior Researcher, Security Ericsson AB Ericsson Research Färögatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 [email protected]<mailto:[email protected]> www.ericsson.com<http://www.ericsson.com/> [http://www.ericsson.com/]<http://www.ericsson.com/> This Communication is Confidential. We only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
