Alex, pardon if I’m telling you things you know (but it doesn’t sound like you know them).
Recipient_structure [3.1.2.1] and [Context Information Structure] are temporary data structures that both the sender and the receiver must construct in memory. They contain the algorithm ID of the bulk encryption algorithm (which might or might not be AEAD) in multi-recipient COSE messages. They are authenticated by the public key material used for the COSE_Recipient structure. [Context Information Structure] comes from a very general NIST publication [SP800-56A] that discusses all manner of public key encryption schemes. [Context Information Structure] is intended to be useful to shore up public key encryption schemes that are very weak, ones no one would use. It wasn’t really designed by a standards body like the IETF. It’s more of an academic paper documenting possible approaches. It took me a long time to understand [Context Information Structure] and I’m still only semi confident about it. In my opinion it has been propagated from one standard to another without anyone thinking about it from a practical, implementable security engineering view. We write extensive security considerations worried about not-too-security-smart engineers doing bad things; then, on the other hand, the security engineering burden from [Context Information Structure] is way out there. COSE HPKE doesn’t use [Context Information Structure], but it does use Recipient_structure [3.1.2.1] which I hope will replace [Context Information Structure] in other COSE configurations — my second concern. I am very sure that HPKE security was thought through. It went through the IRTF, not the IETF. COSE HPKE however brings a COSE layer that didn’t go through the IRTF — my first concern. LL [SP800-56A]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf > On Jun 16, 2025, at 4:09 PM, Alexander Stein <[email protected]> > wrote: > > Sigh, a correction from my previous email with some completely unrelated > content from copy-pasting on a slow workstation, my inline comment this time > is a coherent question without the random unrelated sentence, I am not > approving or disapproving here. Apologies. > > On 6/16/25 7:06 PM, Alexander Stein wrote: > >> First off, thanks for a very thorough, detailed, and transparent analysis as >> an author. More topical questions below are inline. >> >> On 6/16/25 4:04 PM, Laurence Lundblade wrote: >> >>> There ARE use cases for non-AEAD ciphers like disk encryption. >>> >>> Non-AEAD ciphers can be safe in COSE if the COSE_recipient [5.1] >>> authenticates the ID of the non-AEAD cipher. (It also seems safer for the >>> public key layer above the AEAD to authenticate the ID than >>> self-authentication of the AEAD ID by the AEAD). >>> >>> COSE-HPKE doesn’t allow non-AEAD in HPKE Direct Encryption Mode [3.1.1], >>> but it does in HPKE Key Encryption Mode (multiple recipients) [3.1.2]. >>> >>> - COSE HPKE makes non-AEAD safe with the next_layer_alg member in the >>> Recipient_structure [3.1.2.1] >>> - COSE algs -25 to -28 [Direct Key Agreement] make non-AEAD safe with >>> AlgorithmID in the [Context Information Structure] >>> - COSE algs -29 to -34 [Key Agreement with Key Wrap] does NOT because key >>> wrap (which doesn’t authenticate) is in between the level 0 bulk encryption >>> and the Context Information Structure >>> >>> I have two concerns with publishing COSE-HPKE: >>> >>> First, I’m nervous about the amount of security analysis performed on the >>> Recipient_structure [3.1.2.1]. I authored it and believe it is sound, but I >>> don’t recall it being thoroughly blessed by others. >>> >>> Second, I think Recipient_structure [3.1.2.1] is a major candidate to solve >>> the problem with COSE algs -29 to -34. It would also be used to eliminate >>> the use of the [Context Information Structure], which I consider very >>> obscure and an impediment to the adoption of COSE encryption. I oppose the >>> solution of an additional KDF layer proposed in [cek-hkdf] because it adds >>> a wasteful layer and retains the burdensome [Context Information >>> Structure]. It would be nice for the security fix for -29 to -34 [Key >>> Agreement with Key Wrap] to be the same as used in COSE HPKE, but I don’t >>> feel enough analysis has been done to know that Recipient_structure >>> [3.1.2.1] is sufficient to replace the [Context Information Structure > > I read this section a few times slowly, and I cannot tell if the concerns or > possible mitigations are addressed given great detail here. Is the last > sentence in this section a hint towards a shared theme with these concerns as > they pertain to non-AEAD ciphers or am I off the mark? > >>> I know we’re not supposed to admit any intellectual weakness whatsoever in >>> the IETF, but this stuff makes my head hurt. The security analysis here is >>> not easy, so I’m cautious. We missed the LAMPS attack for years. >>> >>> LL >>> >>> [3.1.1]:https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html#name-hpke-direct-encryption-mode >>> [3.1.2]:https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html#name-hpke-key-encryption-mode >>> [3.1.2.1]:https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html#name-hpke-key-encryption-mode >>> [Direct Key >>> Agreement]:https://www.rfc-editor.org/rfc/rfc9053.html#name-direct-key-agreement >>> [Context Information >>> Structure]:https://www.rfc-editor.org/rfc/rfc9053.html#name-context-information-structu >>> [Key Agreement with Key >>> Wrap]:https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap >>> [5.1]:https://www.rfc-editor.org/rfc/rfc9052.html#name-enveloped-cose-structure >>> [cek-hkdf] >>> :https://www.ietf.org/archive/id/draft-tschofenig-cose-cek-hkdf-sha256-02.html >>> >>> _______________________________________________ >>> COSE mailing list [email protected] <mailto:[email protected]> >>> To unsubscribe send an email [email protected] >>> <mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
