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] To unsubscribe send an email to [email protected]
