On Sat, Jul 20, 2024 at 10:15:09PM +0000, lgl island-resort.com wrote: > 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).
That HPKE does not need it does not mean it is not necessary. AD-capable encryption (which HPKE is) has Enc Structure. KDF has Context Information Structure. The Context Information Structure actually carries some necessary duties: - Protects the protected headers. - Breaks commutativity in ECDH-SS. - Mixes in salt for ECDH-SS. - Prevents key material reuse across algorithms. However, the present design of CIS is not great. If redesigning CIS, here are the items I would put in: - Algorithm ID at layer using this key. - Key/IV flag. - Output material length. - Protected headers. - Salt (optional). - Sender public key / Ephremeral key (ECDH only). - Recipient public key (ECDH only). - Application-specified Party U identity (optional). - Application-specified Party V identity (optional). - Application-specified context info (optional). The public keys are there for ECDH in order to guard against attacks from ECDH not being IND-CCA, and to break commutativity. The keys are limited to ECDH because: - Those do not make sense for direct+KDF. - Those are unnecessary for KEM, as KEMs can be assumed IND-CCA. (Good thing, as those keys are annoyingly large.) And for intra-layer KDF, I would use leaner structure: - Algorithm ID at layer using this key. - Key/IV flag. - Output material length. - Salt (optional). > 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. Actually, that is not full fix because COSE does not have chain of authentication for algorithms. For full fix, one would need new header that causes KDF step to be inserted between the input key (not from KDF!) and encryption. Such thing is also useful for Direct Encryption. > 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. Yes, it has some pitfalls. Especially with Party*Info stuff. > Third, it is confusing as it stands in for Enc_structure sometimes > (and that is hard to understand). I don't find that 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. I don't think CIS should be eliminated, as it is necessary. Just redesigned to remove footguns. > 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. Enc_structure versus CIS is easy: - If you are doing AD-capable encryption, it is Enc_structure. - If you are doing KDF, it is CIS. And on reading source code: There is stuff that RFC 9052/9053 are clear about, but no implementation supports. Like key wrapping using chacha20-poly1305. ... Plus some actually unclear stuff that is not implemented anywhere. > 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. Moreover, it does not allow anything except its registered list of algorithms. > It doesn’t directly support multiple recipients. COSE does not need that, because how AEAD algorithms work in COSE. > The solution for -29 through -34 can and should be the same as the > solution for COSE-HPKE. No, it can not. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
