I have not read the processing parts in detail. Here are comments on the first and last sections of the document.
Cheers, John - Somewhere I suggest adding the following sentence from TLS 1.3: "Applications SHOULD also enforce minimum and maximum key sizes. For example, certification paths containing keys or signatures weaker than 2048-bit RSA or 224-bit ECC are not appropriate for secure applications." This is as true for TLS 1.0, 1.1, and 1.2 as for TLS 1.3 - Section 1 "Compared to currently prevalent cryptosystems such as RSA, ECC offers" I think this should be updated, ECDHE is already very well-spread. - Section 1 "This is illustrated in the following table, based on [Lenstra_Verheul], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them." The key sizes for DH/DSA/RSA does not seem to be based on the Lenstra-Verheuls equations which gives much higher key sizes for DH/DSA/RSA. The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I suggest either: A) Fully based the table on NIST recommendation, which means keeping DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric. B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then I would say that this is not [Lenstra_Verheul], but rather [RFC3766], [Lenstra 2004], [ECRYPT 2012]. I think these three all use the same equation. C) Just remove DH/DSA/RSA as the draft is about ECC. - Section 2 "However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy." True, but I think it gives the wrong impression. I think the additional cost is negligible. I don't have any TLS benchmarks but for i5-6600, bench.cr.yp.to gives: ronald3072 decrypt 8776864 cycles ronald3072 sign 8781842 cycles curve25519 keygen 163200 cycles curve25519 compute 165816 cycles That's only 3.8% overhead for crypto, and much less if calculated for the whole handshake. I suggest removing the sentence, or writing that the additional server cost for forward secrecy is negligible and well worth it. - Section 6 "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256" Should this be "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"? I don't think the document should recommend support of cipher suites without forward secrecy. - Section 7 "documemts" -> "documents" - Section 7 "NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO NIST CURVES." I suggest using the excellent explanation in RFC7748 as a basis. Suggestion: "Modern curves such X25519 and X448 [RFC7748] are preferable as they lend themselves to constant-time implementation and an exception-free scalar multiplication that is resistant to a wide range of side-channel attacks, including timing and cache attacks. For more information see [SafeCurves]." [SafeCurves] https://safecurves.cr.yp.to/ - Section 7 "Substantial additional information on elliptic curve choice can be found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]". I think it is better to refer people to [SafeCurves]. - Section 7 The paragraph about structure gives the impression that "F_p with p random" is the optimal choice. I think this should be expanded with more information explaining why we do not recommend random curves. 1) That random curves are hard to protect against side-channel attacks. 2) Non-random curves are significantly faster, so that for a fixed number of operations, p can be much larger for non-random curves. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
