[core] Re: Review of draft-ietf-core-oscore-groupcomm-17

[chrysn <[e-mail]>]

> While there are points which I'm still reviewing in more detail, and
> some remarks based on the latest version, what I can start with is a
> list of items I found neither changed nor mentioned in a response (or I
> missed where that happened). Many of those may easily be fine, just want
> to make sure none of that is getting lost:

There are three more items on that same list -- these are related to
each other and less directly associated to a single section, so I may
have missed changes that should have addressed them, but my impression
so far is that they could still be relevant (items copied from the
original review; those where I have more detailed comments come in the
next thread):

* 2.5.1.1/2.5.1.2 Reboot and Total Loss, and related "invalid replay
  window" sections:

  There are two aspects to replay protection:

  * Nonce reuse: Can I respond to this message without using an own
    Partial IV? From this PoV, it's OK to initialize with "valid" in
    section 2.5.1.1.

  * Replay detection: Have I never processed this request before? From
    that PoV, the device is prone to processing requests again that it
    has processed before, and it'd be advisable to initialize the replay
    window with "not valid" (triggering the 2.5.1.2 item 2 mechanism).

  (Message freshness is a third aspect, that's related insofar as that
  message freshness can be used to infer absence of replays).

  So after reading 2.5.1.1, it appears we mainly care about nonce reuse
  (which is absolutely critical), and treat replay protection more
  sloppily. Treating replay protection sloppily is, in my opinion, often
  fine depending on the message (I've sketched a bit on that in [3]),
  but so far that has not been taken up in OSCORE.

  Inconsistently, when 2.5.1.2 talks of silent servers (which can't do
  the Echo dance to re-initialize their replay windows), the only option
  described for a silent server is to wait for a rekeying, whereas it
  already has all the properties a regular server gains by doing 2.5.1.2
  item 1 (retrieve a new security context) implicitly: It will not do
  nonce-reuse (because it never sends anything), and it will be just as
  prone to replays as a server that just obtained a new security
  context. So by the standards of everything else, silent servers could
  just keep going. (But 6.4 implies that replay protection is just as
  good as with regular OSCORE, so getting a new security context may
  *not* be good enough).

* 10. Challenge-Response synchronization: I don't think it's a good idea
  to allow this mechanism when there is no pairwise mode. If the server
  protects the follow-up request (the one with the Echo) in group mode,
  even if it sends it to a unicast address, that request could be
  replayed to any server that already processed the request's original
  instance. This leads to request being processed twice.

  The whole section is quite hard to process, as it mixes the topics of
  initializing a replay window and finding freshness properties. In
  particular, it speaks of not delivering non-fresh requests requests to
  the application, when generally freshness is not an absolute term, and
  can often only be judged by the application that sets the
  requirements. The large-enough gap mechanism in introduced in this
  section is weird to me:

  If, as a server, my concern is that a malicious party is delaying
  requests to me (say, a sensor sends values every 5 seconds with a
  max-age of 11 seconds, and the attacker delays messages such that the
  server receives a single message every 9 seconds), then if anything, a
  large gap is an indication of *not* being under attack any more -- and
  is thus a bad criterion. IMO the level of freshness that is implied
  here is unobtainable without excessive synchronization, at which point
  it is easier to rekey frequently (thus ensuring that the request is
  more recent than the last rekeying).

  The challenge-response mechanism makes sense for recovering a replay
  window, particularly for reusing the the client's PIVs -- where it is
  nice to have, but not critical to have (because it's always an option
  to take an own PIV instead). It makes some sense for avoiding
  duplicate processing of requests, but whether it's necessary depends
  on the application semantics (not really needed for idempotent
  requests). For freshness, I'm not convinced the full screen page of
  spec text gives any benefits.

* A.2 freshness: Unlike for general freshness (difficult, see above),
  freshness in the sense of the last item of A.2 (ie. ordering of
  messages) is a good goal.

  The term freshness is not well defined here. The use for ordering is
  inconsistent with the term's use in RFC9175 (to which this document
  doesn't explicitly defer, but whose mechanisms it uses for freshnes),
  as RFC9175 freshness is a measure of when the message was sent on the
  recipient's time scale, whereas the message ordering used here is on
  the sender's time scale.

  As a note, when implementing Group OSCORE for constrained devices, I
  would likely not attempt to provide any total order of received
  messages to the application. For received requests, it will need to
  suffice that the request is not replayed (ie., that I'll only send
  every request once to the application). For responses, the two easy
  behaviors are to "accept responses in any sequence" or to "accept only
  the latest and discard all other" messages. There might be a third
  option to allow the application to allocate some counter (so that
  families of responses could each go through an accept-only-the-latest)
  filter. Keeping a persistent total order on all messages received for
  a request is likely not practical without extra allocations in the
  first place.


BR
c

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