[core] Review of draft-ietf-core-oscore-groupcomm-07

[Christian Amsüss <[e-mail]>]

Hello gropucomm authors,

(I'll try to skip issues Jim already found)

* Silent server: I don't see why the role as a client is described as
  independent of being a silent server; doesn't the role as a client
  automatically give it a sender context that that can be used in server
  role just as well?

  Would a proxy (say, one that serves a remote client accessing a local
  multicast group) that verifies the client's legitimacy based on its
  signature as a group member classify as a "silent server", and if so,
  wouldn't "silent member" be more fitting?

  ("Bonus question": Can such a proxy be provisioned with the public key
  of the client but not the group key material?)

* At some point in reading this, it would be comforting to be ensured
  that however the keys are provisioned, I don't need to provision every
  member with every other member's keys. (Eg. in a bipartite setup of
  clients and servers, clients only need recipient contexts of servers
  and vice versa). The line that does this now is "from which messages
  are received" -- is that visible enough?

* 2.5: OSCORE terminology on sequence numbers has so far not used
  "wrapping" semantics, and only spoke of integers -- that those tend to
  wrap is a programming language specific thing, and especially in the
  typical 40-bit space is rarely the default. I could have sworn the
  OSCORE document talks of sequence number "exhaustion", but it doesn't;
  either way, "An endpoint can eventually exhaust its own ..." might be
  a better wording. (If wrapping needs to be mentioned, I think it
  should rather be in "If an implementation's integers only support
  wrapping addition, the implementation MUST detect a wrap and treat the
  context as exhausted instead.")

  (Also in 10.11)

* 3.: I'd appreciate a reference to static-static diffie-hellman shared
  secrets.

* general (but in particular 4.2, and "That Sender ID is valid only
  within that group, and is unique within the group"): This all works
  under the assumption that kid and kid-context are used in a
  hierarchical way of kid residing "under" the kid-context, and that the
  GM may assign any kid to a given node because the GM is in control of
  the whole kid-context. This is not true if the client is also using
  RFC8631 B.2 mode -- then, it needs to reserve some kid across all
  kid-context. (It'd be tempting to partition those by whether a
  multicast address is involved a request, but the Echo recovery happens
  on unicast even when using group OSCORE).

  It might be that this requires some adaptation in the way B.2 is used
  in applications (eg. that they make their ID1 always start with some
  agreed-on prefix that the group manager will not use).

* 4.3.2: Why does theo Signing AAD need to cover OSCORE_option? 

  <del>Things in the option that could be manipulated are the flags
  (pairwise selects a different key), kid and kid context (which select
  different keys) and partial IV changes the nonce -- of those, only the
  Partial IV change would make the signature check succeed, and even
  then, the AEAD will fail.

  If it's only about the Partial IV and actually necessary, a bstr that
  only encodes the PartialIV instead of OSCORE_option would make it
  easier to obtain bounds for the size of the aad_array
  serialization.</del>

  *grml*, section 10.6 talks about that. I suppose that *does* require
  that the AAD can be long enough to contain the longest possible OSCORE
  option.

* 5.: I have the impression this means to say that in pairwise mode, the
  payload is as in RFC8613 and not as in the first bullet, but doesn't.

* general (manifests in 5.1): It'd help understanding the structure if
  there was a note around the ciphertext saying that this is a 28 byte
  ciphertext created from a, say, 12 byte request and including a
  16 byte tag.

* 7.1.1 and later observation handling: Does letting observations run
  through a re-keying open us up to the risk that the client could
  receive the same KID again, start its sequence numbers anew, sends out
  a different observation on the same (KID, PIV) pair (but a different
  key) and the responses get mixed up?

  (Maybe observations just need to terminate on rekeying, like they do
  when your IP addresses change?)

* 7.2 (and 7.4): Is there any prescribed order between counter signature
  and AEAD verification? With the caveats of the below 9.1.1 comments,
  can the client forego verifying the AEAD tag if it verifies the
  signature first?

* 7.3: The same concerns as in 7.1.1 apply here where the different
  security contexts are used in request and response.

  Especially, why is the SHOULD on taking a new partial IV not a MUST?
  After all, the use of the original Partial IV is scoped over the Key
  IDs, and using the requester Partial IV in the new security context
  both for answering requests from this and from the old securty context
  (and thus, the old kid space) is inviting nonce reuse.

  My current impression is that in well-thought-through applications,
  the late updates can work well enough even in constrained applications
  to not take the risks of crossing contexts between requests and
  responses.

* 9.1.1: I had a lot of text here but found that Jim already said it
  better. If found to be secure, this at least needs concrete guidance
  of which stream cipher to use to replace which AEAD algorithm.

* 10.5 or wherever that fits: The namespacing considerations we've
  recently rolled in the OCF call might apply here as well. Unlike in
  non-group OSCORE where the recipient is the authority of its recipient
  IDs and can shard them as it pleases, in a group the group authority
  (whoever allowed taking that group IP address) can shard the group IDs
  between different GMs that manage groups on the same address, if such
  a thing does at all make sense to deploy.

  (I placed this on "or wherever that fits" because while what's said in
  10.5 is true on the security side, I'd very much like things to be
  designed that way that devices don't ever need to try multiple
  decryptions. One practical reason is that decryption can often be done
  in-place, but libraries don't promise to keep the old ciphertext
  intact when decryption fails).

* Counter Signature Parameters Registry and following: Given how tightly
  this is tied into the COSE registry, has it been considered to make
  this an extension there? This would increase visibility of the
  parameters registry to those who enter new counter signature
  algorithms into COSE, and encourage them to describe the parameters
  right away.

* The 'encoded as specified in the "Parameters" field' of 4.3.{1,2} and
  the parameters description of 11.2 miss some glue to me. I suppose
  that the parameters field is a CDDL expression, which would be such
  glue (ie. an EdDSA with kty=1 and crv=2 would be encoded as CBOR `[1,
  2]`), but that is not explicit.

* 11.3: For the assignment of OSCORE Flag Bit 2: Is this only used for
  group OSCORE, or can this be usd in other situations where both parties have
  (or can have) static-static keys?

  If it is particular to group OSCORE, it might make sense to leave its
  meaning in non-group-OSCORE setups undefined. (A kid/kid-context
  combination needs to be recognized as a group or non-group key with
  either value, so the remaining value is free for non-group
  applications). In that light, flipping the bit's value might be
  worth considering, as "pair-wise mode" is the default for non-group
  OSCORE. (AFAIR there was a "has counter-signature" bit in earlier
  drafts. Why was that changed, just because "0" is the more natural
  default value in group OSCORE?)

* E.2: This is basically a trust (freshness) on first use -- but why is
  the first use discarded? An attacker can send in two consecutive
  requests just as well as one, so the server could relay the first
  request to the application just as well.

* Appendix E in general: As I understand, sending a Partial IV in the
  "Protecting the Response" step is as optional as in regular OSCORE:
  you can do it, and need to under some circumstances, but for
  efficiency you don't unless you need to.

  If that is the case, E.1 and E.2 should be explicit about that while
  they may be good enough for the application's freshness requirements,
  they are not good enough for using the request's Partial IV, at least
  if the baseline synchronization state can ever get lost.

* E.3: That unicast repeated request 

  "otherwise, the request is silently discarded": Why? This could just
  be due to a client that has taken its time, I'd have expected
  "otherwise, a 4.01 (Unauthorized) including an Echo option is sent as
  above".

  And does the server need a time interval here? I'd implement Echo as a
  random-per-bootup (or taken-from-own-sequence-numbers) source, and
  don't see a cryptographic reason to concern myself with time there.
  All that matters is that the new request is one the client sent after
  my server came up, so it can't have been responded to in an earlier
  life.

  I disagree with the "all group members [need to] understand the
  elective Echo option" approach; Echo is defined as elective, and
  unknown Echo values can be ignored. Last but not least, two servers
  could easily arrive at the same  Echo value. Using pairwise security
  contexts would be much more suitable for the re-request, and not rely
  on ignoring messages on mismatching Echo values, and should always be
  used with this mode; see discussion at
  https://github.com/core-wg/oscore-groupcomm/issues/26.

* Appendix G: "Senders MUST NOT use [pairwise with] multiple
  recipients": I was confused at first as to why this is not a "can
  not", and only later realized this is to keep clients that want to
  address a single server from just broadcasting a request with
  pairwise encryption. This could be clearer.

* G.1: The mechanism for address discovery is an odd mixture of
  vagueness and concreteness. Suggestion to replace the three last
  paragraph and its bullets: "To make this information available,
  servers MAY provide a resource to which a client can send a request
  for a server identified by its sender ID, or a set thereof. Details of
  such an interface are out of scope for this document."

* G, "Note that no changes are made to the AEAD nonce and AAD.": I'll
  need to think this through again when implementing it.

Over all, a thing I'm looking forward to implementing in aiocoap.

Kind regards
Christian

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