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

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

Hello oscore-groupcomm authors,

as part of having read the updated document, I'm going through the
review that initiated many of the changes for open points.

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:

* 2.1.6 "The label is an ASCII string": Given that the type element in
  the info array is a CBOR item, it can only be a byte or a text string;
  I assume that the latter is meant. (And these don't typically contain
  trailing NUL bytes).

* 4., "OSCORE uses the untagged COSE_Encrypt0 structure with an
  Authenticated Encryption with Associated Data (AEAD) algorithm":
  After compression, it doesn't matter any more whether it's the tagged
  or the untagged COSE_Encrypt0 structure.

* In verifying that the now explicit arithmetic for the Ed25519 /
  Curve25519 mapping is what I'm using, I found that libsodium (from
  where I lifted my implementation) since very recently contains a note
  on its ed25519_..._to_curve25519 functions that "An alternative is do
  the ECDH operation over the Edwards curve, avoiding the conversion
  altogether"[2].

  Given that a lot of work has gone into making the Ed25519/X25519
  conversion work, I hope that no easy alternatives to this moderately
  cumbersome process (admittedly, it's the hardest in terms of spec
  text, and probably easier on the target CPU than on the programmer)
  have been missed, but I'd appreciate if someone who understood what's
  actually going on here could verify that whatever they're proposing
  doesn't apply here.

* Now that authentication credentials are a thing in Group OSCORE, and
  these can in particular be CWTs or ?509 certificates that can have
  chains leading there: Does this mean that for deployments such as the
  pairwise-only one sketched at the last paragraph above Section 1.1,
  it's possible to run a group on more-or-less unchanged group key
  material, and members join by means of learning the current key
  material and obtaining a signed certificate to their key? (When they
  then arrive in the group, they start communicating, and when their
  peers need the credentials, those can be disseminated in a
  self-contained way, eg. by the new node itself -- without involving
  the GM).

* Is the attack described in 13.7 ("Cross-group Message Injection")
  still possible now that request_kid_context and gm_cred are part of
  the eAAD? My impression (but without thorough checking) is that it
  wouldn't work any more because the gm_cred differ.

  Having the OSCORE option in the signature is a bit convoluted in
  implementations (not impossible, and can be optimized out, but
  requires some mental gymnastics), and AIU 13.7 is the only reason to
  have the OSCORE option in the eAAD in the first place.

* A.1, forward and backward security: These look more like objectives
  (A.2) than assumptions (A.1) to me.

* 13.5.1, "the recipient can still try to process the received message
  using the old retained Security Context as a second attempt": Why is
  that a second attempt? This makes it sound like the server attempts
  decryption, encounters a bad signature, and then retries with the old
  context, whereas what actually happens is that the server sees the old
  Gid, and still has that security context around.

* 13.14: Does it make sense to show client aliveness? The server gets
  client aliveness relative to the last rekeying, but an application
  that requires aliveness exceeding that would cause a storm of Echo
  options that could have better been handled by 1:1 communication (or
  more frequent rekeying) in the first place.

BR
Christian

[2]: https://github.com/jedisct1/libsodium-doc/commit/0732187608798b7b6d48d291ed1562fb28cf1e36 / https://doc.libsodium.org/advanced/ed25519-curve25519

-- 
Most people would leave. Not us. We're Vikings. We have stubbornness
issues.
  -- Hiccup, son of Stoic