On Tue, Sep 17, 2024 at 10:33:11AM +0200, [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.
You can not trust _any_ explicit context. > 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. Unfortunately, alg in COSE and JOSE has incorrect granularity for key algorithm binding, with some equivalence classes including multiple algorithms (e.g., -25, -29, -30 and -31 in COSE). And with COSE-HPKE/JOSE-HPKE, every HPKE alg that works with given key is in the same equivalence class. In JOSE, this gets even more annoying, as equivalent algorithms might have different types and thus not be interchangeable. However, including alg information in any "oct" key seems like a good idea. > 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. Yes, context information in headers is not useful. The application should be able to optionally specify implicit context that is then authenticated. In latest draft, that can be done by using the external_aad input. In JOSE there is no good way to include implcit context (JOSE-HPKE has a way, but requires HPKE implementation beyond what spec requires). However, arguably contexts are only useful for ECDH-SS (to break the symmetry and to inject a nonce). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
