Skip to main content

11. Security Considerations

  1. 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 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; Section 8.5 of [RFC9052] forbids combining "direct" recipient algorithms with other modes.

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

The use of 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 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 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 [RFC9147] is based on the number of records that are sent. This should map well to the number of messages sent when using COSE, so that analysis should hold here as well, under the assumption that the COSE messages are roughly the same size as DTLS records. 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.

Last updated on