On Sep 17, 2024, at 1:33 AM, [email protected] wrote:
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. I’m open to other arrangements than the current draft, but would to achieve these: - Not use Context Info Structure. In particularly not require implementors to read and understand NIST SP800-56. - Be much more clear than the COSE RFCs are about the encryption context(s) - Address the AEAD downgrade attack 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. I’m asking myself if this indicates a problem with PGP, CMS and lots of other formats that we’ve been using for decades. LL
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
