Subject: [Uta] TLS BCP 01 Draft

From: Trevor Freeman <[email-masked]>
Date: Mon, 30 Jun 2014 18:11:15 +0000

General Comments.
There are still no definition on what constitutes best protection against monitoring i.e. what offers best, adequate or minimal protection against monitoring.  Give one of the goal is to move the internet to better protect against this kind of activity, we need to clarify which actions in this draft best enable that goal and not just providing basic interoperability.

Section 3.4 and 4.1 needs to be consolidated as there is a lot of overlap between the two sections.

I think it is good to provide rational behind the recommendations for various cipher sites, it leaves the reader with some interpretation between that and the actual cipher suites. It would be better to actually list the cipher suites in question to remove any scope for misinterpretation.

Also support for the SNI is missing from the draft. This is a mandatory for any application interacting with a service.

Specific comments.

Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it ok to fall back to TLS 1.0 but not SSL 3.0 if both offer the same security?

Section 3.4.
bullet 3.  Implementations MUST NOT negotiate cipher suites with an effective key length of less than 112
bullet 5   Implementations SHOULD prefer cipher suites with greater than 128 bits of effective key length
bullet 6  Given the foregoing considerations, implementation of the following suites are recommended (in order of preference)

*         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

*         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

*         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

*         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Rational: In the preceding bullet we give preference to cipher with 256 bit key

Also client MUST send an ec_point_formats extension

3.5 public key lengths.
Public key algorithms based on integer factorization or discrete logarithms MUST use a public key size of at least 2048 bits.

4.1
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the first proposal to any server.
Rational: Section 3.4 bullet 5 says we give preference to ciphers stronger than 128 bits.

Clients MUST include the "supported elliptic curve" extension

Trevor