I've read through draft-ietf-uta-tls-bcp-07 and it looks pretty good. I have a few minor comments:
1. Section 4.3 This section recommends key lengths for modular DH keys, but is silent on ECDH keys. The Named Curve Registry has 160-bit curves which should be avoided. We should probably recommend that elliptic curves of at least 192 bits be used (some folks might argue for 224 bits here). "The named curve registry contains 160-bit elliptic curves which are considered to be roughly equivalent to only an 80-bit symmetric key [ECRYPT-II]. The use of curves of less than 192-bits is NOT RECOMMENDED." In the last paragraph the use of the term fingerprint seems odd and perhaps misleading. I think the term hash algorithm would be better: "the use of the SHA-256 hash algorithm is RECOMMENDED" 2. Section 4.4 The rational section makes it sound like there is limited support for ECDHE. I think this is changing quite rapidly and we should be promoting ECDHE suites more. Also, I've also run into some folks who are under the misconception that using ECC cipher suites require the use of ECDSA certificates. In addition, I think the document should mention that many DHE implementations also have security issues with validating group parameters (this is mentioned in the attacks draft, but it might also be good to reference it here). Suggestion for rational in section 4.4: "Rationale: Although Elliptic Curve Cryptography is widely deployed there are some communities where its uptake has been limited for several reasons, including its complexity compared to modular arithmetic and longstanding perceptions of IPR concerns (which, for the most part, have now been resolved [RFC6090 <https://tools.ietf.org/html/rfc6090>]). Note that ECDHE cipher suites exist for both RSA and ECDSA certificates so moving to ECDHE cipher suites does not require moving away from RSA based certificates. On the other hand, there are two related issues hindering effective use of modular Diffie-Hellman cipher suites in TLS: o There are no protocol mechanisms to negotiate the DH groups or parameter lengths supported by client and server. o There are widely deployed client implementations that reject received DH parameters if they are longer than 1024 bits. In addition, several implementations do not perform appropriate validation of group parameters and are vulnerable to attacks referenced in section 2.9 of [UTA-Attacks]." Cheers, Joe
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
