Change:
Addressing issue : Reverting to previous method of updating replay window (section B.1.2, text was previously in 7.5) Removing item 2 in section 7.5
Hi, I do not think that the new suggested Echo procedure specified in 7.5 and B.1.2 is secure with GCM. The procedure intentionally reuses a nonce. As the Plaintext and/or AAD changes, I think the nonce reuse will allow an attacker to calculate the GCM authentication key H, therefore compromising integrity for all following messages the server receives. I don't think we want a procedure that is dependant on the AEAD algorithm. Are there any ways to fix this or should we revert to the previous procedure where the server first need to make sure that it uses a fresh nonce and then send Echo? What do you think NAME ? In Section 7.5, bullet 2 The endpoints can update the server’s Replay Window by using the Echo option [I-D.ietf-core-echo-request-tag], see Appendix B.1.2 for an example. This method only updates the Replay Window and does not update the server’s Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using Appendix B.1.1) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using Appendix B.1.1). In Appendix B.1.2
Yes you are correct. I was only thinking of the use of CCM which does not have this problem.
I merged PR - reverting to the processing in -15.
I close this issue now, if there are still comments we can reopen it.

Discussion:
3.2.2. <del> The Sender Sequence Number is initialized to 0.  The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </del> <ins> The Sender Sequence Number is initialized to 0. The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </ins> 3.3.

This parameter SHALL be present in requests.  The Partial IV SHALL be present in responses to Observe registrations (see observe-registration), otherwise the Partial IV will not <del> typically be present in responses. </del> <ins> typically be present in responses (for one exception, see reboot-replay). </ins> The 'kid' parameter.  The value is set to the Sender ID.  This parameter SHALL be present in requests and will not typically

updating the mutable parts of the security context (Sender Sequence Number, and Replay Window).  This requires that the mutable parts of the security context are available throughout the <del> lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see seq- numb and reboot-replay for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The endpoints can update the server's Replay Window by using the Echo option I-D.ietf-core-echo-request-tag, see reboot-replay for an example.  This method only updates the Replay Window and does not update the server's Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using seq-numb) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using seq- numb). </del> <ins> lifetime of the device, or that the device can establish safe security context after loss of mutable security context data. Examples is given based on careful use of non-volatile memory, see seq-numb, and additionally the use of the Echo option, see reboot- replay.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. </ins> The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see master-secret-