Hi, John Thanks for the review. See my responses below:
> On 23 Nov 2016, at 12:15, John Mattsson <john.matts...@ericsson.com> wrote: > > 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 I can add a sentence like that, but the draft does even better: It deprecates all curves smaller than 256-bit ECC. Now it’s true that this draft is about TLS, not PKIX, so this only forces the public key in the EE certificate to be at least 256-bit, but in general CA keys are no weaker than EE keys. I will add such a sentence , though. > - Section 1 > "Compared to currently prevalent cryptosystems such as RSA, ECC offers" > > I think this should be updated, ECDHE is already very well-spread. Yes, this is copied from 4492. How about: “Compared to previous cryptosystems such as RSA and finite-field diffie-hellman, ECC offers…" > - 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. I’m inclined to get rid of this table and all the text from “This is illustrated…” entirely. ECC is by now in wide use. We don’t need to “sell” it any more. so unless someone would like to make a PR with better text, I will just get rid of it. > > - 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. Makes sense. How about: OLD: However, the computational cost incurred by a server is higher NEW: The computational cost incurred by a server is marginally higher > > - 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. Definitely. It would be a very poor show to deprecate this ciphersuite (along with all other ECDH_RSA and ECDH_ECDSA ciphersuites), declare that all ciphersuites have forward secrecy, and then make this (sort of ) MTI. Will fix. > > - Section 7 > "documemts" -> “documents" OK > > - 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/ Cool. Will add. > - 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]. In addition, OK. I don’t think we should remove everything else, especially when unlike 7748 this draft is specifying NIST curves, and the choice for them was not in [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. I think the explanation above covers this, but we may want to mention that even the NIST curves are faster than random. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
