Draft: draft-ietf-core-object-security

Commentary: as discussed some hours ago . Notes about proxies go to the mailing list for further routing . Closes : 
 The mailing list discussion that the kind of extension is not covered by observation . Could you try to sit together with  to talk this out ? ( I 'd be happy to join in , but as both all of you and  are in Singapore right now , you might want to grab any short - term occasion to talk to the man who wrote the boo^WRFC on observation ) 
 There is no mention of observation renewal ( cf . ) in OSCORE , and I think there should be , because there are two possible interpretations , hinging on " All options MUST be identical to those in the original request except for the set of ETag Options " : ETag is encoded in the message , thus the message may change and be encrypted with a new nonce . is no ETag in an OSCORE observe , therefore the only valid renewal is renewal with the very message with the same nonce ( it 's not nonce reuse when the message is identical ) can be sent . Either is consistent with the current text ; option 2 would be the easy path because the text addition would just say that " Renewal of the observation and updating of the ETags is not supported at OSCORE level . The underlying transport 's observation can be renewed , but its Object - Security options and FETCH payload can not be different from the original request " . Advantages of 1 : The set of ETags can be updated as with regular Observation . A new request PartIV is sent to the server , so the client can have freshness of new messages relative to the renewal operation without stopping the observation and starting a new one . Disadvantages of 1 : A proxy might be tripped up by an option that is not an ETag changing in an update . ( Though it should n't , really -- given that the observation cancellation could have been lost , it should just view such an event as the cancellation of an old and the establishing of a new observation , and forward it accordingly . ) Nonce ambiguity : The client needs to be prepared to receive updates with the old nonce ( which would read as AEAD decryption failures ) after having renewed an observation , and must n't be upset by them ( read : must not send anything back to the server that would jeopardize the observation ) . I think I 'd prefer 1 , but would be fine with either given the ambiguity - of - nonce point . 
 I do n't understand the concept of observe renewal . I have always treated this as a new observe and not as a renewal . 
 I 'd describe observe renewal as another Request message on the same token that should elicit a more immediate response to confirm that the observation is still on ( and if it was n't , register one anew transparently ) . It is practically answered either by a piggybacked ACK 2.05 Content , or by an empty ACK , in which case there is no message that 's explicitly " the " response to the refresh , but the client will still expect something back on that token within however long it is ready to wait for an initial response . That one can update the set of ETags while doing so is a practical feature and at the same time an extreme load the request / response model ( now not only can an exchange have multiple responses , it can also have multiple requests ) , so I prefer to read it as the second request implicitly canceling the first silently ( " The token was re - used , so obviously it has been retired by the client " ) and establishing a new observation , which is so much easier on the request / response model and looks exactly the same on the wire . ( Those considerations also made me propose 1 ) .
Paragraph (version A):
The Observe option in the CoAP request may be legitimately removed by
a proxy.  If the Observe option is removed from a CoAP request by a
proxy, then the server can still verify the request (as a non-Observe
request), and produce a non-Observe response.  If the OSCORE client
receives a response to an Observe request without an Outer Observe
value, then it MUST verify the response as a non-Observe response.
If the OSCORE client reveives a response to a non-Observe request
with an Outer Observe value, the processing is covered in processing.
Paragraph (version B):
The Observe option in the CoAP request may be legitimately removed by
a proxy.  If the Observe option is removed from a CoAP request by a
proxy, then the server can still verify the request (as a non-Observe
request), and produce a non-Observe response.  If the OSCORE client
receives a response to an Observe request without an Outer Observe
value, then it MUST verify the response as a non-Observe response.
If the OSCORE client receives a response to a non-Observe request
with an Outer Observe value, the processing is covered in processing.
Paragraph (version B):
Clients can re-register observations to ensure that the observation
is still active and establish freshness again (RFC7641
Section 3.3.1).  When an OSCORE observation is refreshed, not only
the ETags, but also the partial IV (and thus the payload and Object-
Security option) change.  The server uses the new request's Partial
IV as the "request_piv" of new responses.
Paragraph (version A):
For responses, the message binding guarantees that a response is not
older than its request.  For responses without Observe, this gives
strong absolute freshness.  For responses with Observe, the absolute
freshness gets weaker with time, and it is RECOMMENDED that the
client regularly restart the observation.
Paragraph (version B):
For responses, the message binding guarantees that a response is not
older than its request.  For responses without Observe, this gives
strong absolute freshness.  For responses with Observe, the absolute
freshness gets weaker with time, and it is RECOMMENDED that the
client regularly re-register the observation.
Paragraph (version B):
An error condition occuring while processing a response in an
observation does not cancel the observation.  A client MUST NOT react
to failure in step 7 by re-registering the observation immediately.