Hi John and Scott,
For even greater clarity, you might want to address these points: If the receiver uses an x-only ladder (e.g. Brier-Joye) and re-uses private ECC key, then, upon decoding the peer’s compress public key (represented via x), the receiver ought to check that x^3+ax+b is a square? [SafeCurves says to do check this, but, of course, also adds the twist secure can avoid this check.] Actually, it's a little bit tricky to find invalid x where y = (x^3+a+b)^((p+1)/4) gives (x,y) of low order. I mentioned this to CFRG: https://mailarchive.ietf.org/arch/msg/cfrg/nzxkGIo97GlIGszJirvS_TFUUio/ Despite this extra wrinkle of difficulty, an attack is avoided by validating a decompressed point. (So, I’m not sure if the statement “the implementation will naturally detect invalid points when it …” is entirely realistic. [Safecurves say this where, by the way?] I’m a little confused by the sentence “As not even the sign of the y-coordinate is encoded, compact representation avoids ‘benign malleability’ where an attacker changes the sign”. Is this about the attack changing (r,s) to (r,p-s)? Since r and s are integers, there are no y coordinates in play, the change from (r,s) to (r,p-s) is possible regardless of y coordinates. (Ok, there is a connection to y coordinates: a point R, of which r is the x coordinate (mod p), does implicitly change by way of negating its y coordinate, but R is not sent in ECDSA, instead, ECDSA only sends x (via r). I.e. r is already a “compact” version of R.) Best regards, Dan From: TLS <tls-boun...@ietf.org> On Behalf Of Scott Fluhrer (sfluhrer) Sent: Tuesday, January 17, 2023 11:10 AM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; TLS@ietf.org Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-compact-ecc-00.txt CAUTION - This email is from an external source. Please be cautious with links and attachments. (go/taginfo) 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 <mailto:tls-boun...@ietf.org> > On Behalf Of John Mattsson Sent: Monday, January 16, 2023 4:45 PM To: TLS@ietf.org <mailto: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 <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.txt__;!!JoeW-IhCUkS0Jg!bXX9aX8L0HIfLffteRT0Z-k17pud7MctUPpkwqCx12ez0wqF93lS8DM_ZM8QIdT8cJithLMJF4TzW1kFGC6OIvKFwWOXceQ$> Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/__;!!JoeW-IhCUkS0Jg!bXX9aX8L0HIfLffteRT0Z-k17pud7MctUPpkwqCx12ez0wqF93lS8DM_ZM8QIdT8cJithLMJF4TzW1kFGC6OIvKFfSA2oIQ$> Html: https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-00.html__;!!JoeW-IhCUkS0Jg!bXX9aX8L0HIfLffteRT0Z-k17pud7MctUPpkwqCx12ez0wqF93lS8DM_ZM8QIdT8cJithLMJF4TzW1kFGC6OIvKFjWfPvvY$> Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc__;!!JoeW-IhCUkS0Jg!bXX9aX8L0HIfLffteRT0Z-k17pud7MctUPpkwqCx12ez0wqF93lS8DM_ZM8QIdT8cJithLMJF4TzW1kFGC6OIvKFWVqX8lA$> 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 ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
