On Wed, Nov 15, 2023 at 08:35:34PM +0000, lgl island-resort.com wrote: > I want to be explicit about this — The Context Info Structure can > prevent the AES attack presented at IETF 118. This gives credibility > to Context Info Structure. HPKE (not COSE-HPKE) by itself also > prevents this attack. So it’s good to see that work has been done > that anticipated attacks like this.
This is not about context information structure, it is about direct versus indirect recipients. > But, there’s issues with multi-recipient COSE: > > 1) Even though alg ID -29 (section 6.4 of 9053) uses Context Info > Structure, it is vulnerable because key wrap is in hierarchy and it > doesn’t do AEAD and Context Info Structure is not really put to use. > This is kind of a (big?) hole and oversight in RFC 9053. Yes, because -29 is indirect like COSE-HPKE. And I don't think it is actually oversight in RFC 9053 (which mostly comes from RFC 8152). The problem is RFC 9459, which came about much later. > 2) COSE-HPKE in the current draft has Context Info Structure is > optional. So the current draft is clearly not sufficient. (It’s also > not particularly clear on how protected headers are actually > protected). COSE-HPKE is indirect, so Context Information Structure would not help anyway. COSE-HPKE uses CDE of Enc_structure as aad, which protects the protected headers. If application wants to do something smart with context, it can put the fields in external aad. Such things are highly application dependent. > We need to do something thorough about both of these. There’s been > some back and forth between me and Ilari about 2) COSE-HPKE but I > suspect many of you haven’t tracked it. I think COSE-HPKE is wrong place to do anything about this. > Last, I don’t think we have to use Context Info Structure in > COSE-HPKE, but I do think we need to provide an equivalent, because > I think it has earned some credibility because it anticipated this > attack. No, Context Information Structure does not make sense for COSE-HPKE. > What to do about 1) seems tougher. Seems like at least errata > security considerations should be issued warning about this. Anything that deals with 1) will also deal with 2). There already exist effective mitigations COSE implementation can do to avoid this attack: 1) If authenticated decryption fails, do not return anything besides an error. AND 2) Either do not implement RFC 9459, or only implement it for separate API that will return an error for anything else. This sounds like material for COSE/JOSE best practices document. For COSE-level fix, I think have already posted rough outline on how that can be done. To summarize: Add new parameter valid for other-type AEAD that causes KDF step on the incoming key before use in the AEAD. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
