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].
Actually maybe I take my approval back: is there a purposeful
distinction between a Statement and Receipt in the content format? Isn't
a Receipt just a Signed Statement with specific content in the
unprotected header? 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 --cose@ietf.org
To unsubscribe send an email tocose-le...@ietf.org
_______________________________________________
COSE mailing list -- cose@ietf.org
To unsubscribe send an email to cose-le...@ietf.org
