Thanks Scott, I agree that such a validation check should be mandatory. The intention was to keep all validation requirements from RFC 8422 and only change the encoding. I will make that clear in the next update.
The “can” was intended to mean that you can do the validation before using and API or you can let the API do the point validation. My understanding is that some libraries provide point validation, and some don’t. >Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to >this sort of attack. I would personally be fine with that. I tried to make X25519 and EdDSA MTI in EDHOC but people really wanted P-256, ECDSA, and SHA-256. I would assume that the same is true for cTLS, which is the main focus of the draft. X25519 seems to already be the de facto standard for HTTPS. Cheers, John From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Date: Tuesday, 17 January 2023 at 17:13 To: John Mattsson <john.matts...@ericsson.com>, TLS@ietf.org <tls@ietf.org> Subject: RE: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt It looks good; just one comment: The current draft says (section 3.2) A full validation according to Section 5.6.2.3.3 of [SP-800-56A] can be achieved by also checking that 0 ≤ x < p and that y^2 ≡ x^3 + a ⋅ x + b (mod p) (emphasis added). I believe such a validation check should be mandatory. For the curves listed in the draft, the corresponding twists are not of prime order; hence someone injecting an invalid curve point has some advantage at recovering the peer’s secret value (and hence if an implementation reuses ECDHE private values, that gives them some advantage at recovering the keys for other sessions). Yes, this is not a major point (this relies on the device under attack reusing private values, which they’re not supposed to do); on the other hand, the expense is fairly minimal (just computing y^2 (after all, you’ve already computed x^3+a+b), and the additional complexity needed to perform this check), hence I believe it is warranted. Alternatively, you can mandate a safe curve (e.g. X25519), which is immune to this sort of attack. From: TLS <tls-boun...@ietf.org> On Behalf Of John Mattsson Sent: Monday, January 16, 2023 4:45 PM To: TLS@ietf.org Subject: [TLS] FW: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt Hi, I wrote a draft specifying new optimal fixed-length encodings for ECDHE and ECDHA with the NIST P-curves. This seems to be exactly what is needed for cTLS. The new encodings are defined as a subset of the old encodings which hopefully makes them easy to implement. Cheers, John From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Monday, 16 January 2023 at 22:38 To: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>, John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Subject: New Version Notification for draft-mattsson-tls-compact-ecc-00.txt A new version of I-D, draft-mattsson-tls-compact-ecc-00.txt has been successfully submitted by John Preuß Mattsson and posted to the IETF repository. Name: draft-mattsson-tls-compact-ecc Revision: 00 Title: Compact ECDHE and ECDSA Encodings for TLS 1.3 Document date: 2023-01-16 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/ Html: https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc Abstract: The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. The IETF Secretariat
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
