Draft: draft-ietf-core-object-security

Commentary: 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 do n'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  ? What do you think ? 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  B.1.2 for an example . This method only updates the Replay Window and does not update the server ’s    , so it MUST be complemented by a method for updating the Sender Sequence Number ( e.g. by using   ) 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   ) . 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 .
Paragraph (version A):
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.
Paragraph (version B):
The Sender Sequence Number is initialized to 0.
Paragraph (version B):
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.
Paragraph (version A):
The 'Partial IV' parameter.  The value is set to the Sender
Sequence Number.  All leading bytes of value zero SHALL be
removed when encoding the Partial IV, except in the case of
Partial IV of value 0 which is encoded to the byte string 0x00.
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
typically be present in responses.
Paragraph (version B):
The 'Partial IV' parameter.  The value is set to the Sender
Sequence Number.  All leading bytes of value zero SHALL be
removed when encoding the Partial IV, except in the case of
Partial IV of value 0 which is encoded to the byte string 0x00.
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
typically be present in responses (for one exception, see
reboot-replay).
Paragraph (version A):
The endpoints can reuse an existing Security Context after
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
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.
Paragraph (version A):
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).
Paragraph (version B):
The endpoints can reuse an existing Security Context after
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
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.