Draft: draft-ietf-core-object-security

Commentary: According to 's comments : remove notification numbers changed the order of the list one method : use of echo to update replay window ( when server does not uses its own sender sequence number in responses ) editorial (  apparently I can not ask you to review via github , maybe because you are not part of the CoRE WG github organization ? But yes , if you could check that this answers your comments , that 'd be great ) 
 I reviewed and made the following changes :  's method move as number 2 Some clarifications of that method Changing motivations which made less sense when the methods were is reverse order Moved the details of  's method to B.1 where other detailed methods are  non - volatile methods under one heading in appendix B , and changed reference ( So I violated the name of this PR since it extends to appendix B.1 )
Paragraph (version A):
The endpoints can run a key exchange protocol providing forward
secrecy resulting in a fresh Master Secret, from which an entirely
new Security Context is derived.  This requires a good source of
randomness, and additionally, the transmission and processing of
the protocol may have a non-negligible cost in terms of, e.g.,
power consumption.
Paragraph (version A):
An alternative is to use a trusted-third party assisted key
establishment protocol such as I-D.ietf-ace-oscore-profile, which
may be more lightweight and may not require additional randomness.
Paragraph (version A):
The endpoints can reuse an existing shared Master Secret and
derive new Sender and Recipient Contexts.  This typically requires
a good source of randomness and a message exchange, but not as
large performance impact as a key exchange protocol, and no
trusted third party.  See master-secret-multiple for an example.
Paragraph (version A):
Under certain circumstances an endpoint can reuse an existing
Security Context with updated Sender Sequence Number, Replay
Window, and Notification Numbers.  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
master-secret-once 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 choice of method may depend on capabilities of the devices
deployed and the solution architecture.  This document RECOMMENDS the
use of a key exchange protocol.
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 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 B):
The endpoints can only 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 if the client can not guarantee non-
reuse of its own Sender Sequence Numbers (e.g. by using seq-numb).
Paragraph (version B):
The endpoints can reuse an existing shared Master Secret and
derive new Sender and Recipient Contexts, see master-secret-
multiple for an example.  This typically requires a good source of
randomness.
Paragraph (version B):
The endpoints can use a trusted-third party assisted key
establishment protocol such as I-D.ietf-ace-oscore-profile.  This
requires the execution of three-party protocol and may require a
good source of randomness.
Paragraph (version B):
The endpoints can run a key exchange protocol providing forward
secrecy resulting in a fresh Master Secret, from which an entirely
new Security Context is derived.  This requires a good source of
randomness, and additionally, the transmission and processing of
the protocol may have a non-negligible cost, e.g. in terms of
power consumption.
Paragraph (version B):
The endpoints need to be configured with information about which
method is used.  The choice of method may depend on capabilities of
the devices deployed and the solution architecture.  Using a key
exchange protocol is necessary for deployments that require forward
secrecy.