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]
