I proposed these goals so we could understand the trade-offs for various solutions. Maybe we decided not to meet all of them, but at least we know what we’re getting.
It’s true that solving the security issue doesn’t require eliminating Context Information Structure but 1) it is related 2) I’ve slowly come to the conclusion that Context Information Structure is kind of an awful liability in COSE. HPKE is fine without it, establishing that it isn’t necessary. I wrote these goals in response to the proposal from Hannes. As I understand the proposal, it adds another layer to an already messy set of layers and doesn’t address goals 2) and 3). LL On Jul 20, 2024, at 2:41 PM, Ken Takayama <[email protected]> wrote: Laurence, To clarify, lamps attack requires 1) modifying encryption algorithm AES-GCM/CCM to AES-CBC, 2) the same content encryption key to be used for downgraded algorithm AES-CBC, and 3) the recipient to return the decrypted plaintext to the attacker. I think there are also other solutions. To prevent condition 1), the RFC 9459 (AES-CBC and AES-CTR for COSE) requires these non-AEAD algorithms to be used in conjunction with an authentication and integrity mechanism. If the recipient conducts such validation and returns "authentication failure", the attack cannot succeed. I admit that this solution is not perfect, because it depends on the implementation of the recipient side, and the sender may not control it. Hannes is proposing another approach, inserting KDF just before the content encryption and decryption. <https://datatracker.ietf.org/doc/draft-tschofenig-cose-cek-hkdf-sha256/> Different content encryption keys will be derived for different content encryption algorithms, and it prevents condition 2). I think it works also for COSE-HPKE. Best, Ken 2024年7月21日(日) 5:23 lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>>: Here’s 4 proposed goals for the work to address the attack presented in Lamps at IETF 118. 1) Fully address the attack presented in Lamps at IETF 118 in Prague Little explanation needed: IETF protocols should close out vulnerabilities like this. This does imply that we will eventually need a new RFC that defines replacements for algorithm IDs -29 though -34, the “ECDH with key wrap” algorithm in section 3.4.1. 2) Eliminate Context Information Structure The Context Information Structure defined in RFC 9053 section 5.2 has many problems. First it requires world-class cryptographer analysis to understand how to use it for each use case safely. We’re not doing our job in the IETF if that level of expertise is required to deploy a protocol. By comparison, HPKE doesn’t require such. Also by comparison, we go to lengths to warn or prohibit counter mode, because we expect implementors of IETF protocols aren’t very smart. Anyone smart enough to figure out Context Information Structure is easily smart enough to know not to use counter mode. Second, it has fields in it that are unnecessary for most use cases, particularly the common use where the RNG is of high quality and fresh keys are used for every message. Third, it is confusing as it stands in for Enc_structure sometimes (and that is hard to understand). In eliminating Context Information Structure, alternate facilities to achieve the same should be provided for use cases that need them, but the alternatives should be simpler, clearer and not be present when not needed. They might be optional COSE header parameters. In summary, Context Information Structure is an unwieldy and an unnecessary burden. 3) Clarify use of rules for creating a COSE_Recipient RFC 9052 and 9053 are not very clear about the rules for creating a COSE_Recipient, particularly the use of Enc_structure vs Context Information Structure. Some of us have resorted to reading Jim’s source code. 4) Same solution for both COSE-HPKE and the replacement for algorithms ID -29 through -34, the “ECDH with key wrap” algorithm in section 3.4.1. COSE-HPKE is probably not a solution for all use cases. It doesn’t allow non-aead algorithms. It doesn’t directly support multiple recipients. It is larger and more complex which might be too much for some constrained environments. We need a replacement for algorithm IDs -29 through -34. The solution for -29 through -34 can and should be the same as the solution for COSE-HPKE. LL _______________________________________________ COSE mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
