Group Object Security for Constrained RESTful Environments (Group OSCORE)
draft-ietf-core-oscore-groupcomm-28

# Andy Newton, ART AD, comments for draft-ietf-core-oscore-groupcomm-27
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-27.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Patrik Fältström for the ARTART review.

While I'm balloting No Obj on this draft, I'd like a response to the comments I've listed below.  

This draft is appears to be quite complicated (and require knowledge of no less than 9-10 specifications).  A quick review shows that there are plenty of places where signat encryption, and key agreement are confused. Crisper use of terminology here would be best. I've given an example below, and I'd be happy to help work on this.  

Thanks to Mališa Vučinić for their secdir review. 



Section 1.1:  Use of the phrase 'Master Secret' is being replaced (TLS has already removed it).  Will it be replaced here, maybe with a note to the pre existing specifications? [Note:  this applies to 'Master xxxx']

Section 2, Authentication Credential Format:  This section references Section 2.1.5, which then references Section 2.4 without much clarifying information.  Recommend skipping the double ref and just reference Section 2.4 here. 

Section 2, Signature Encryption Key:  Not entirely sure what this means.  Is this a symmetric key? (it is apparently an AEAD or something like that.

Section 2, pairwise mode:  static-static DH to derived a shared secret, etc. isn't common...  for a reason.  Please explain why it is ok in this specification.

Section 2.1.7, para 2:  It is odd that AES CBC mode is being suggested, give the issues with the CBC mode.  What makes CBC mode more appropriate than CTR mode?

Section 2.5:  EdDSA and ECDSA are mentioned in the section, I assume one would use ECDH for key agreement (vice encryption).  While this section doesn't need every detail to be perfect, it needs to be closer than this.  Perhaps something like:  'Elliptic Curve Cryptographic public/private key pairs can be used for both signature and key agreement'.  

Section 5.1, para 3:  'remain active indefinitely',  seems like a bad idea, especially if the group is rekeyed.  Maybe put a cap on how long?  Especially from a cryptography point of view.

Section 14.11:  Is secure distribution of these keys discussed in any of the many of specifications referenced?  It does not appear to be addressed in this draft.  (nor is it listed as out of scope).

Thanks for preparing this document and thanks also to Joerg Ott for his heplfpul TSV-ART review. 

1) I include one topic here from the TSV-ART with an additional question:

Section 12.2, 2nd para states that "when possible, the delivery of rekeying
messages should use a reliable transport [...]"

This seems to suggest that an unreliable -- and possibly non-congestion
controlled -- transport is fine, too.  This appears risky if rapid membership
changes occur or are suggested in some way as this could cause floods of
rekeying messages.  Especially since (4th para), "The Group Manager MUST rekey
the group without undue delay when one or more endpoints leave the group."

An additional question: Is this a SHOULD use a reliable transport?
----

2) In the following:
/The use of an
   unreliable transport MUST NOT forego enforcing congestion control as
   appropriate for that transport./

(a) Could this be rewritten as a requirement as something like:
/A transport (reliable or unreliable) MUST enforce appropriate congestion control./
(b) I am content with the requirement, but it would be better if this requirement also pointed to some examples where this was satisfied in other documents.

Thanks to the authors and the WG for their work on this document.

I have a question about the normative references that I am moving from DISCUSS to COMMENTS following a similar discussion with the rest of the IESG in a recent telechat: 

Why would the reference to an IANA registry COSE.Algorithms be a normative reference instead of an informative reference. I find the actual normative portions are in RFCs 8613, 5869, and 9053 - all of which are correctly categorized as normative. Isn't the pointer to the registry just an helpful reference for readers?

Hi Marco, Göran, Francesca, John, and Rikard, 

Thanks for the effort put into this spec. I appreciate the discussion in Section 12, in particular.

Please find below some comments: 

# Re-keying & Observe

CURRENT:
   *  Long exchange: an exchange of messages associated with a request
      that is a group request and/or an Observe request [RFC7641].

I wonder whether there any impact of key change on installed observed. 

# To whom?

CURRENT:
   How the Security Context is established by the group members is out
   of scope for this document, but if there is more than one Security
   Context applicable to a message, then the endpoints MUST be able to
                                                            ^^^^^^^^^^
   tell which Security Context was latest established.
   ^^^^^^

# Capability

CURRENT:
   An endpoint of the group may use the group mode (see Section 7), the
   pairwise mode (see Section 8), or both, depending on the modes it
   supports and on the parameters of the Security Context.  

Is there a need to know in advance with a remote endpoint supports one or all these modes? Does that have impact on how contexts are established?

# How the limit is know? Can that be retrieved from the system and exposed to the app?

CURRENT:
   An endpoint may admit a maximum number of Recipient Contexts for a
   same Security Context, e.g., due to memory limitations.  After
   reaching that limit, the endpoint has to delete a current Recipient
   Context to install a new one (see Section 2.6.1.2).  It is up to the
   application to define policies for Recipient Contexts to delete.

# Tracking/Logging 

CURRENT:
   The Security Context may contain a large and variable number of
   Recipient Contexts.  While Group OSCORE in itself does not establish
   a maximum number of Recipient Contexts, there are circumstances by
   which implementations might choose to discard Recipient Contexts or
   have to do so in accordance with enforced application policies.  Such
   circumstances include the need to reclaim memory or other resources
   on the node hosting the endpoint, for example because the predefined
   maximum number of Recipient Contexts has been reached in the Security
   Context (see Section 2.2).

How these discarded contexts are tracked? Are there some king of alarm/notification to warn this?

# Is there a reason what the Group Manager may not be informed? Shouldn’t such event be logged locally, btw? Shouldn’t the manager be contacted prior to exhaustion and not wait for full exhaustion?

CURRENT:
   Upon exhausting the Sender Sequence Number space, the endpoint MUST
   NOT use this Security Context to protect further messages including a
   Partial IV.

   When approaching the exhaustion of the Sender Sequence Number space,
   the endpoint SHOULD inform the Group Manager, retrieve new Security
   Context parameters from the Group Manager (see Section 2.6.3), and
   use them to derive a new Sender Context (see Section 2.2).  

# Not new behavior: cite as quote

OLD: 
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent
   over multicast MUST be Non-confirmable, and thus are not
   retransmitted by the CoAP messaging layer.  

NEW:
   As per [RFC7252][I-D.ietf-core-groupcomm-bis], “group requests sent
   over multicast MUST be Non-confirmable”, and thus are not
   retransmitted by the CoAP messaging layer.  

And 

OLD:
   According to Section 5.2.3 of [RFC7252], responses to Non-confirmable
   group requests SHOULD also be Non-confirmable,

NEW:
   According to Section 5.2.3 of [RFC7252], “responses to Non-confirmable
   group requests SHOULD also be Non-confirmable”,

Cheers,
Med

Thank you to Paul Kyzivat for the GENART review.

# Orie Steele, ART AD, comments for draft-ietf-core-oscore-groupcomm-27 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-27.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to Patrik Fältström for the ARTART review.
The review contains security related comments which I am not in a position to comment on.

### public key algorithm is fully described?

```
776	   If authentication credentials are CBOR Web Tokens (CWTs) or CWT
777	   Claims Sets (CCSs), the public key algorithm is fully described by a
778	   COSE key type and its "kty" and "crv" parameters.
```

https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves


Later:

```
897	      In case the other endpoint's public key has COSE Key Type "EC2"
898	      [RFC9053] (e.g., for the curves P-256, P-384, and P-521), then the
899	      public key is used as is.  In case the other endpoint's public key
900	      has COSE Key Type "OKP" [RFC9053], the procedure is described in
901	      Section 5 of [RFC7748].  In particular, if the public key is for
902	      X25519 or X448, it is used as is.  Otherwise, if the public key is
903	      for the curve Ed25519 or Ed448, it is first mapped to Montgomery
904	      coordinates (see Section 2.5.2).
```

X25519 is curve value 4, but Ed25519 is curve value 6, both are OKP (good).
However, P-256 is curve value 1, and supports many algorithms and is of key type EC2.

> This document defines these algorithms to be used with the curves P-256, P-384, P-521, X25519, and X448. Implementations MUST verify that the key type and curve are correct. 

https://www.rfc-editor.org/rfc/rfc9053.html#section-6.3.1-8

I don't understand what "fully described" means in this context.
A key type and curve do not fully describe a key agreement or signature algorithm in absence of additional information.

Note I am concerned about long term use of static-static DiffieHellman keys, and would appreciate an answer to my question below.



 
        The AEAD Algorithm (see Section 3.1 of [RFC8613]) SHALL identify

I think this should just say "identifies" without a SHALL ?

        The HKDF Algorithm (see Section 3.1 of [RFC8613]) SHALL identify the

same

        The ID Context parameter (see Sections 3.1 and 3.3 of [RFC8613]) SHALL contain

same

        The Common IV parameter (see Section 3.1 of [RFC8613]) SHALL identify the

same

Section 2.1.7

Probably state that an AEAD is prefered over non-AEAD ?

Section 2.1.9

        deriving a keystream to encrypt/decrypt

Maybe call this a symmetric key instead of keystream ? Same for the use of KEYSTREAM?


It could be better clarified what the lifetime is of static-static DH keys (eg that
rejoining the group, a reboot, etc results in a new "long term" identifier with respect
to the static-static DH keys. I could not figure out from this document whether there is
any maximum keylife for these type of keys before a rekey/rejoin event must happen.


Section 14

        The key pair can, for example, be generated by the endpoint or provisioned during manufacturing.

I assume this key is only used for authenticating to Group Manager(s)
and not for the static-static DiffieHellman because that would be severely
lacking in forward security.

        A possible way to ameliorate

Please find another word for "ameliorate". If I don't know this word, many more people won't
know what it means.

        Randomness requirements for security are described in [RFC4086].

I think 4086 is very oudated and bad, and wouldn't mind not using it and instead stating something
about using proper cryptographic strength randomness provided by the OS/hardware instead.