Original text:
RFC8613) typically only breaks the security of the data in the forged packet.  After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD

Reviewer comments:
NAME Do you or David have any comment on the formulation?
NAME We needed to merge this PR to prepare for -17, but we are of course still interested in your comments :-)
No comment to do ;). It's good.
This is the outcome of the work by Baptiste Cottier and David Pointcheval related to The conclusions form Baptiste and David is that after receiving message4 the Initiator has authenticated the Responder with a strength of the combined MACs in message2 and message4. I.e. if both MACs are 64 bits, they work together as a 128 bit MAC. The same thing apply to application messages such as OSCORE used as message 4,5,6,..... but this comes with the additional requirement that the security association has to be terminated and EDHOC redone in the case that verification of the OSCORE MAC fails. The same apply to the draft-ietf-core-oscore-edhoc where 2 MACs are sent in flight 3 URL The same priciple should apply to modes with signatures where a signature in message2 combined with a MAC in message_4 gives the strenght of the signature and the MAC combined. Baptiste and David have not investigated this formally.
Good. Terminology comment: You use first "authenticated with 128-bit security" and then "128-bit mutual authentication". I assume that means the same in security terms (although one is unilateral and the other mutual). No mentioning of online attacks here. Is it clear how that relates to "64-bit security against online brute force attacks" which is stated in another security consideration? "can be achieved after verification of the first OSCORE Response". This is correct in its brevity, but the use of "verification" gives the impression that it is the verification of OSCORE Response is what makes this achieved, rather than it is the completion of the processing of the OSCORE request and OSCORE response that are the moments in time when, with the appropriate measures, security can be achieved. Perhaps replace "verification" with "completion".

Revised text:
RFC8613) typically only breaks the security of the data in the forged packet. <ins> As the EDHOC protocol is terminated when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures, MACs (including MAC in AEAD).  As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4).  The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is rerun when verification of the first MACs in the application protocol fail.  As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response. </ins> After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD