Subject: [core] Proxies and observations: "All options MUST be identical"

From: Christian Amsüss <[email-masked]>
Date: Mon, 13 Nov 2017 17:54:21 +0100

Hello CoRE and LWIG groups,

when discussing re-registration of observations in the context of
OSCORE with Jim and the OSCORE authors, we stumbled upon the sentence
"All options MUST be identical to those in the original request except
for the set of ETag Options." about this in RFC7641.

This is something that servers, especially proxies, should not try to
enforce, because every case of a request with differing options (or
FETCH payload) could just as well be a new observation from the client
on the token whose observation cancellation got lost, or the client
simply rebooted.

I'd like to take that recommendation down somewhere (or have it
challenged before it's relied on by OSCORE). Where would that fit?
RFC7641 errata? draft-ietf-lwig-coap? 

Best regards
Christian

PS. if you're interested in the context: ETag is an encrypted option in
OSCORE. Changing the ETag means re-encrypting the message, which
requires a new nonce and thus also changes the Content-Security option
-- and thus we'll allow that there. I think it's OK to do that because
the underlying rule is unenforcable anyway.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Nov 2017 01:02:09 +0800

> for the set of ETag Options." about this in RFC7641.

This is a requirement on the client in order to effect a re-registration of interest.

> on the token whose observation cancellation got lost, or the client

Right.  I don’t think enforcing that all requests are re-registration requests is in the server requirements for 7641?

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 13 Nov 2017 18:23:59 +0100

> on the token whose observation cancellation got lost, or the client

If it's a new observation, then the client should not use a token that
is still in use. RFC 7252 Section 5.3.1:

   The client SHOULD generate tokens in such a way that tokens currently
   in use for a given source/destination endpoint pair are unique.

This requirement is slightly relaxed when a client wants to
re-register its interest in a resource, but only under narrow
circumstances: namely that the request is (almost) identical.

This is a requirement for clients, however.

In case a server (or proxy in the role of a server) receives an
observation request with a token that is still in use, it must kill
the existing observation. RFC 7641 Section 4.1:

   The entry in the list of observers is keyed by the client endpoint
   and the token specified by the client in the request.  If an entry
   with a matching endpoint/token pair is already present in the list
   (which, for example, happens when the client wishes to reinforce its
   interest in a resource), the server MUST NOT add a new entry but MUST
   replace or update the existing one.

So the server already doesn't enforce the client requirement.

Klaus

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 13 Nov 2017 18:43:14 +0100

Hello Klaus,

thanks for your reply.

>    in use for a given source/destination endpoint pair are unique.

My hypothetical client was using the "but I already cancelled, it's not
in use any more, didn't you get the NON?" defense -- but fair point.

> [...]

Hmpf, that would mean that a correct proxy would treat an OSCORE
re-registration with new (encrypted) ETag set as a new observation. It
would determine that the old observation is over, cancel its observation
to the origin server and start a new one, presumably (under the
abovementioned) using a new token. Should work, but it's a new
observation at the origin.

A very smart proxy might even notice that rather than cancelling the
observation, it can start the new one on the same token and thus do both
cancellation and new registration in a single packet (making things
magically smoother), but that might be considered smart to the extent of
specification abusal.

A less smart proxy might even decide to let the old observation cancel
itself by forgetting it and open the new one, resulting in two
simultaenous registrations at the origin -- not ideal, but maybe
tolerable.

Do you think there is a practical way around this that is not "OSCORE
observations can never be renewed (can never have a bit different, thus
no new nonce, no new freshness and no new ETags), and to renew an OSCORE
observation you have to cancel the old one and register a new one"?

Best regards
Christian

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 13 Nov 2017 19:40:05 +0100

> in use any more, didn't you get the NON?" defense -- but fair point.

It's not the client alone who decides when a token is no longer in use.

> observation at the origin.

Right.

> magically smoother), but that might be considered smart to the extent of

If the proxy finds that the new observation request from the client is
(almost) identical to the previous observation request from the
client, then this behavior is exactly the one intended.

The proxy could also try to do it when the requests are not identical,
but this would violate the "MUST be identical" client requirement,
although it might technically work due to the "MUST replace or update
the existing" server requirement. I wouldn't assume that any proxy
does it in this case.

> observation you have to cancel the old one and register a new one"?

At first glance, I don't see any.

Klaus