Hi Trevor, thanks for your review. Please see my comments in line.
On 06/30/2014 09:11 PM, Trevor Freeman wrote:
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.
These are lofty goals indeed. But the draft's goal is not to define
"best protection against monitoring", let alone to define 3 levels of
such protection. It is simply to remediate issues with the way TLS is
currently deployed. I don't think we "just provide basic
interoperability", I believe we provide strictly better security, within
the constraints of current technology and interoperability.
Section 3.4 and 4.1 needs to be consolidated as there is a lot of
overlap between the two sections.
I am not sure about the overlap, and would appreciate specific points.
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.
The first part of Sec. 3.4 provides more than half a page of rationale
for the cipher suite selection.
Also support for the SNI is missing from the draft. This is a mandatory
for any application interacting with a service.
Quoting my own earlier response to you (my mail of June 21): "I'm all in
favor of using SNI. But as far as the draft goes, I believe this is an
operational decision, and so we should not include such a recommendation."
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?
This is a good question. I believe the answer is, because much of the
server population still only supports TLS 1.0, and if we recommend
otherwise, the recommendation will be ignored for (justified)
interoperability reasons. But I may be wrong about the prevalence of
such servers.
Section 3.4.
bullet 3. Implementations MUST NOT negotiate cipher suites with an
effective key length of less than 112
I can live with this.
bullet 5 Implementations SHOULD prefer cipher suites with greater than
128 bits of effective key length
No, this contradicts our recommendation, and IMO is too strict for the
current state of the industry. In other words, people are perfectly
happy with AES-128 today and it is NOT our goal to push to AES-256.
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
Again, we disagree on this point.
Also client MUST send an ec_point_formats extension
As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status for
these extensions. I don't think we should be repeating or overriding that."
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.
This is currently a SHOULD-level requirement (we use the equivalent term
RECOMMENDED). Given the problems with modular DH in TLS, I'm afraid we
cannot mandate >2048 because of the interoperability issues, and because
some people might value forward secrecy over key length.
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.
Disagree again.
Clients MUST include the “supported elliptic curve” extension
See above.
Thanks,
Yaron
Trevor
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
