Maybe the chairs have an idea here, but seems to me it comes down to consensus in the WG as to whether there has been enough security analysis and we want to publish. If the consensus is “no”, then we have to find resources amongst ourselves and our organizations to do the analysis. We wait for those resources to be found and complete the analysis work to publish or somehow the consensus turns to “yes” on the security issues.
I don’t think we can rely on the AD, IESG or IETF-level review. (Other SDOs, like FIDO, have budget and means to hire people to do security analysis, but I don’t think IETF does. Or one of the companies that sponsor us folks working here in the IETF might think it is important enough to pay for an analysis, but I don’t think that’s likely for this work). LL > On Jun 16, 2025, at 2:43 PM, Henk Birkholz <[email protected]> wrote: > > Hi Laurence, > > in general, I am in support in moving this I-D forward. You brought up two > relevant concerns: > > 1.) more security analysis. Can this become part of the IESG review or do you > have another approach in mind? > > 2.) and more security analysis (for reuse of recipient structure instead of > an additional kdf layer). > > As an IETF participant, I am able and willing to admit that I cannot do such > security analysis. But is there a realistic actionable approach on the table > to get some in? Or is this a perpetual and somewhat ephemeral blocker? > > > Viele Grüße, > > Henk > > On 16.06.25 22:04, 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 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] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
