Subject: [core] KUDOS and observations

From: Christian Amsüss <[email-masked]>
Date: Thu, 9 Dec 2021 10:10:21 +0100

Hi Rikard,

kept thinking about observation persistence after yesterdays's interim,
hoping this gets us forward:

There can be situations in which client and server disagree on whether
an observation is still active. (There can be in theory, for a client
can always send deregistrations and rely on the server to cancel all
observations on the same resource (identified by roughly the cache key),
but I think that's brittle both because it means clients can never stop
an observation quickly).

When the server starts using a security context, it needs to be sure
whether to keep the observations on or not; if they are left on, it
might immediately produce notifications referring to the previous
context's sequence numbers. (If the server tried to track observations and
cancel them when receiving that same sequence number again, that'd be
pointless because the cryptographically matching responses would
already be on the air). So it's up to the client to ensure non-reuse of
still-acceptable sequence numbers (be it by longjumping or by skipping).

The "p︦" bit you described (it's not in the editors' copy, right?) would
probably go into the "x" field (limiting id_detail from 256 bytes to
still unrealistic 128). Maybe we could take another bit off there that
says "I'm making sure that my observations are good, you can keep
sending me notifications of older observations even on the new key
material". Servers that don't see this bit would stop any observations
still on (any of) the old key(s). Whether the client then does
longjumping, skipping or something else (maybe "I always use the first N
sequence numbers for the semantically same requests so it's OK if they
get reused", or "I have some long-running observations which I establish
with my first N sequence numbers, and then longump only to N+1") is then
up to the client.

BR
c

PS: With this we *would* have a bit in the OSCORE optiojn that needs
protecting. Possibly, "x || id-detail" could go into the key derivation
rather than just id-detail.

PPS: It may help to state clearly that servers may just stop all
observations on rekeying if they don't expect them to be useful, this
would allow constrained servers that don't need it to not do it. Then,
even though observations are not guaranteed by transports to be kept
alive anyway, another flag "I am indeed persisting observations" could
be helpful, which a server that ignores the first bit just never sets.
"Read as any, write as 0" should be a safe thing to do for any
implementation.

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