Hello Klaus, thanks for your reply.
On Mon, Nov 13, 2017 at 06:23:59PM +0100, Klaus Hartke wrote: > 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. 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. > 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: > > [...] > > So the server already doesn't enforce the client requirement. 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 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
