Hi all,
When I presented an update on the COSE HPKE draft at the last IETF meeting (see slides-120-cose-use-of-hpke-with-cose (ietf.org) <https://www.ietf.org> ), Sophie made an insightful remark that got me rethinking the construction of the context information. She noted, "you cannot trust the information in the headers", in response to my presentation. This is particularly relevant because the current draft suggests placing all context information into the header so it is included in the authenticated data. Ideally, when a recipient processes the message, the first step involves using the key ID to retrieve the key required to decrypt the payload (or identify the key used by the key exchange mechanism to derive the content encryption key). Best practices dictate that different keys should be used for different purposes, meaning there should be a one-to-one relationship between the key and the associated algorithm information. For instance, a key designated as a KEK for AES-KW should not be used directly for content encryption. This implies that the parties involved in the communication should avoid including algorithm-related information in the message header. Instead, this information should be retrieved based on the key identifier. Thus, more than just the key ID and the key must be shared between the communicating parties; key-related metadata must also be exchanged. If I understood Sophie correctly, the current approach of relying on header-based context information is not useful. We should reconsider why we are embedding all of this information in the header in the first place, as it may actually weaken security. Ciao Hannes [1] Interestingly, I had already advocated for using the key ID to select all other parameters back in 2015. See [COSE] alg Header Parameter (ietf.org) <https://mailarchive.ietf.org/arch/msg/cose/Ybou-lGY5C2DwYlorI8wRwxlmN0/>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
