Improve motivation part

draft-kwiatkowski-tls-ecdhe-mlkem.md

@@ -47,6 +47,7 @@ author:
 normative:
   rfc7748:
   FIPS203: DOI.10.6028/NIST.FIPS.203
+  SP56C: DOI.10.6028/NIST.SP.800-56Cr2
 
 informative:
   xyber: I-D.tls-westerbaan-xyber768d00-03
@@ -70,25 +71,30 @@ a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE).
 # Introduction
 
 ## Motivation
-ML-KEM is a key encapsulation method (KEM) that is designed to
-withstand cryptanalytic attacks from quantum computers. {{FIPS203}}
-In 2024, X25519Kyber768Draft00 {{xyber}} a hybrid of Kyber, an earlier version of ML-KEM, and X25519 {{xyber}}
-is the most widely deployed PQ/T hybrid.
+ML-KEM is a key encapsulation method (KEM) defined in the {{FIPS203}}. It is designed to
+withstand cryptanalytic attacks from quantum computers.
+
+This document introduces two new supported groups for hybrid post-quantum key
+agreements in TLS 1.3: X25519MLKEM768 and SecP256r1MLKEM768. Both combine ML-KEM-768 with
+ECDH in the manner of {{hybrid}}.
+
+The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, the
+most widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024.
+
+The second one uses secp256r1 (NIST P-256) {{ECDSA}} {{?DSS=DOI.10.6028/NIST.SP.800-186}}. The
+goal of this group is to support a use case that requires both shared secrets to be generated by
+FIPS-approved mechanisms.
+
+Both constructions aim to provide a FIPS-approved key-establishment scheme (as per {{SP56C}}).
 
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
 
 # Negotiated Groups
 
-This document introduces two new supported groups for hybrid post-quantum key
-agreements in TLS 1.3: X25519MLKEM768 and SecP256r1MLKEM768.
-Both combine ML-KEM-768 with ECDH in the manner of {{hybrid}}.
-The first uses X25519 {{rfc7748}} as elliptic curve to match X25519Kyber768Draft00.
-The second uses secp256r1 (NIST P-256) {{ECDSA}} {{?DSS=DOI.10.6028/NIST.SP.800-186}}.
-
 Both groups enable the derivation of TLS session keys using FIPS-approved schemes. NIST's
-special publication 800-56Cr2 {{?SP56C=DOI.10.6028/NIST.SP.800-56Cr2}} approves the usage of HKDF
+special publication 800-56Cr2 {{SP56C}} approves the usage of HKDF
 {{HKDF}} with two distinct shared secrets, with the condition that the first one is computed by
 a FIPS-approved key-establishment scheme. FIPS also requires a certified implementation
 of the scheme, which will remain more ubiqutous for secp256r1 in the coming years.
@@ -99,34 +105,37 @@ and the secp256r1 shared secret first in SecP256r1MLKEM768.
 ## Construction
 
 ### Client share
+
 When the X25519MLKEM768 group is negotiated, the client's key_exchange value
 is the concatenation of the client's ML-KEM-768 encapsulation key
 and the client's X25519 ephemeral share.
-The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519.)
+The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519).
 
 When the SecP256r1MLKEM768 group is negotiated, the client's key_exchange value
 is the concatenation of the secp256r1 ephemeral share and ML-KEM-768 encapsulation key.
-The ECDHE share is the serialized value of
-the uncompressed ECDH point representation as defined in Section 4.2.8.2 of {{!RFC8446}}.
-The size of the client share is 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes for ML-KEM.)
+The ECDHE share is the serialized value of the uncompressed ECDH point representation as
+defined  in Section 4.2.8.2 of {{!RFC8446}}. The size of the client share is 1249 bytes
+(65 bytes for the secp256r1 part and 1184 bytes for ML-KEM).
 
 ### Server share
+
 When the X25519MLKEM768 group is negotiated, the server's key exchange
 value is the concatenation of an ML-KEM ciphertext returned from encapsulation
 to the client's encapsulation key, and the server's ephemeral X25519 share.
-The size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519.)
+The size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).
 
 When the SecP256r1MLKEM768 group is negotiated, the server's key exchange
 value is the concatenation of the server's ephemeral secp256r1 share encoded
-in the same way as the client share
-and an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key.
-The size of the server share is 1153 bytes (1088 bytes for the ML-KEM part and 65 bytes for secp256r1.)
+in the same way as the client share and an ML-KEM ciphertext returned from encapsulation
+to the client's encapsulation key. The size of the server share is 1153 bytes (1088 bytes
+for the ML-KEM part and 65 bytes for secp256r1).
 
 For both groups, the server MUST perform the encapsulation key check
 described in Section 7.3 of {{FIPS203}} on the client's encapsulation
 key, and abort with an illegal_parameter alert if it fails.
 
 ### Shared secret
+
 For X25519MLKEM768, the shared secret is the concatenation of the ML-KEM
 shared secret and the X25519 shared secret. The shared secret is 64 bytes
 (32 bytes for each part).
@@ -143,13 +152,14 @@ The same security considerations as those described in {{hybrid}} apply to the a
 The security analysis relies crucially on the TLS 1.3 message transcript, and one cannot assume a similar
 hybridisation is secure in other protocols.
 
-Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers.
+Implementers are encouraged to use implementations resistant to side-channel attacks,
+especially those that can be applied by remote attackers.
 
 # IANA Considerations
 
-This document requests/registers two new entries to the TLS Supported Groups
- registry, according to the procedures in {{Section 6 of tlsiana}}. These identifiers are to be used with
- the final, ratified by NIST, version of ML-KEM which is specified in {{FIPS203}}.
+This document requests/registers two new entries to the TLS Supported Groups registry, according
+to the procedures in {{Section 6 of tlsiana}}. These identifiers are to be used with the final,
+ratified by NIST, version of ML-KEM which is specified in {{FIPS203}}.
 
 ## SecP256r1MLKEM768