Rephrased TLS integration recommendation section

draft-irtf-cfrg-cpace.md

@@ -236,10 +236,10 @@ For accomodating different application settings, CPace offers the following OPTI
   it is RECOMMENDED to forward this sid value as an additional input for the protocol as this provides security advantages
   and will bind the CPace run to this communication session (see {{sec-considerations}}).
 
-## Optional CPace output
+## Optional CPace outputs
 
 If a session identifier is not available as input at protocol start CPace can optionally produce a session identifier sid\_output
-as output that might be helpful for the application for actions subsequent to the CPace protocol step (see {{sec-sid-output}}).
+as output that might be helpful for the application for actions subsequent to the CPace protocol step (see {{sec-sid-output}}, {{BGHJ24}}).
 
 ## Responsibilities of the application layer
 
@@ -253,8 +253,8 @@ The following tasks are out of the scope of this document and left to the applic
   e.g. by use of a key-derivation function, the clear-text password SHOULD BE encoded according to {{?RFC8265}}.
 
 - The application needs to settle whether CPace is used in the initiator-responder or the symmetric setting, as in the symmetric
-  setting transcripts and concatenation of party identity strings as part of the channel identifier CI
-  must be generated using ordered string concatenation.
+  setting transcripts ordered string concatenation must be used for generating protocol transcripts and when integrating
+  the identity strings A and B into the channel identifier CI.
   In this document we will provide test vectors for both, initiator-responder and symmetric settings.
 
 # CPace cipher suites {#CipherSuites}
@@ -753,29 +753,29 @@ One suitable option that works also in the parallel setting without message orde
 
 ## Integrating CPace in higher-level protocols such as TLS1.3
 
-When integrating CPace into a higher-level protocol such as TLS1.3 {{RFC8446}} it is recommended to let the intermediate key ISK
-take over the role of the shared secret that for other cipher suites
-might be generated by Diffie-Hellman key exchange. Note that unlike a Diffie-Hellman shared secret ISK will also
-mutually authenticate the protocol partners.
+When integrating CPace into a higher-level protocol such as TLS1.3 {{RFC8446}} it is recommended to use ISK
+as shared secret (which might otherwise be generated as part of a Diffie-Hellman key exchange output for other cipher suites).
+
+Note that unlike the shared secret of a Diffie-Hellman protocol run, ISK will also provide mutual implicit authentication of the protocol partners.
 For providing explicit authentication, it is recommended to add a key confirmation round along the lines in {{sec-key-confirmation}},
-such as e.g. done in the "Finished" messages in TLS1.3.
+such as e.g. done in the "Finished" messages in TLS1.3 {{RFC8446}}.
 
 If an embedding protocol uses more than two messages (e.g. four message TLS1.3 {{RFC8446}} flows involving
 a hello-retry message and a repeated client-hello message) it is suggested
 that the CPace layer only considers the two messages used for the CPace run. I.e. it is suggested that
 authenticating the full message sequence involving also the additional messages that might preceed the two CPace messages
-is done under the responsibiity of the embedding protocol.
-This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3).
-Alternatively information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate
-the information and will not require both communication partners to keep state information regarding preceeding messages until after the CPace run.
+is done under the responsibiity of the embedding application protocol.
+This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3 as part of the "Finished" messages).
+Alternatively, information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate
+the information and will not require both communication partners to keep state information regarding preceeding messages in memory until after the CPace run.
 
-In case of TLS 1.3 it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers
-may be added to the client-hello and server-hello messages as part of extension fields.
+In case of TLS 1.3 {{RFC8446}} it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers
+might best be added to the client-hello and server-hello messages as part of extension fields.
 It is recommended to use the full octet stream encoding of the
-client-hello message as parameter ADa. Likewise the encoding of the server-hello would be used for the parameter ADb.
-This approach has the drawback that the public points Ya and Yb might show up duplicated in the hashing operation for
+client-hello message as parameter ADa. Likewise it is recommended to use the encoding of the server-hello message for the parameter ADb.
+This approach has the drawback that the public points Ya and Yb might show up redundantly duplicated in the hashing operation for
 CPace's transcript strings but has the advantage of simplicity and the advantage that all meta-information in the extension fields within the
-client- and server hello fields will become authenticated as part of the ISK.
+client- and server hello fields will always become authenticated as part of the ISK.
 
 ## Calculating a session identifier alongside with the CPace run {#sec-sid-output}