Subject: [Uta] Review of draft-ietf-uta-tls-bcp-01

From: John Mattsson <[email-masked]>
Date: Thu, 24 Jul 2014 21:13:11 +0000

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-masked]<mailto:[email-masked]>
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>