12.11.  Security Considerations

   There are a number of security considerations that need to be taken
   into account by implementers of this specification.  The security
   considerations that are specific to an individual algorithm are
   placed next to the description of the algorithm.  While some
   considerations have been highlighted here, additional considerations
   may be found in the documents listed in the references.

   Implementations need to protect the private key material for all any
   individuals.  Some cases in this document need to be highlighted with
   regard to this issue.

   *  Use of the same key for two different algorithms can leak
      information about the key.  It is therefore recommended that keys
      be restricted to a single algorithm.

   *  Use of "direct" as a recipient algorithm combined with a second
      recipient algorithm exposes the direct key to the second
      recipient.

   *  Several of the algorithms in [RFC9053] this document have limits on the
      number of times that a key can be used without leaking information
      about the key.

   The use of Elliptic Curve Diffie-Hellman (ECDH) ECDH and direct plus KDF (with no key wrap) will not
   directly lead to the private key being leaked; the one-way function
   of the KDF will prevent that.  There is, however, a different issue
   that needs to be addressed.  Having two recipients requires that the
   CEK be shared between two recipients.  The second recipient therefore
   has a CEK that was derived from material that can be used for the
   weak proof of origin.  The second recipient could create a message
   using the same CEK and send it to the first recipient; the first
   recipient would, for either Static-
   Static Static-Static ECDH or direct plus KDF,
   make an assumption that the CEK could be used for proof of origin,
   even though it is from the wrong entity.  If the key wrap step is
   added, then no proof of origin is implied and this is not an issue.

   Although it has been mentioned before, it bears repeating that the
   use of a single key for multiple algorithms has been demonstrated in
   some cases to leak information about a key, providing the opportunity
   for attackers to forge integrity tags or gain information about
   encrypted content.  Binding a key to a single algorithm prevents
   these problems.  Key creators and key consumers are strongly
   encouraged to not only create new keys for each different algorithm,
   but to include that selection of algorithm in any distribution of key
   material and strictly enforce the matching of algorithms in the key
   structure to algorithms in the message structure.  In addition to
   checking that algorithms are correct, the key form needs to be
   checked as well.  Do not use an "EC2" key where an "OKP" key is
   expected.

   Before using a key for transmission, or before acting on information
   received, a trust decision on a key needs to be made.  Is the data or
   action something that the entity associated with the key has a right
   to see or a right to request?  A number of factors are associated
   with this trust decision.  Some highlighted here are:

   *  What are the permissions associated with the key owner?

   *  Is the cryptographic algorithm acceptable in the current context?

   *  Have the restrictions associated with the key, such as algorithm
      or freshness, been checked, and are they correct?

   *  Is the request something that is reasonable, given the current
      state of the application?

   *  Have any security considerations that are part of the message been
      enforced (as specified by the application or "crit" header
      parameter)?

   There are a large number of algorithms presented in this document
   that use nonce values.  For all of the nonces defined in this
   document, there is some type of restriction on the nonce being a
   unique value for either a key or some other conditions.  In all of
   these cases, there is no known requirement on the nonce being both
   unique and unpredictable; under these circumstances, it's reasonable
   to use a counter for creation of the nonce.  In cases where one wants
   the pattern of the nonce to be unpredictable as well as unique, one
   can use a key created for that purpose and encrypt the counter to
   produce the nonce value.

   One area that has been getting exposure is traffic analysis of
   encrypted messages based on the length of the message.  This
   specification does not provide a uniform method for providing padding
   as part of the message structure.  An observer can distinguish
   between two different messages (for example, "YES" and "NO") based on
   the length for all of the content encryption algorithms that are
   defined in [RFC9053]. this document.  This means that it is up to the
   applications to document how content padding is to be done in order
   to prevent or discourage such analysis.  (For example, the text
   strings could be defined as "YES" and "NO ".)

   The analysis done in [RFC9001] is based on the number of records/
   packets that are sent.  This should map well to the number of
   messages sent when using COSE, so that analysis should hold here as
   well.  It needs to be noted that the limits are based on the number
   of messages, but QUIC and DTLS are always pairwise-based endpoints.
   In contrast, [OSCORE-GROUPCOMM] uses COSE in a group communication
   scenario.  Under these circumstances, it may be that no one single
   entity will see all of the messages that are encrypted, and therefore
   no single entity can trigger the rekey operation.