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.