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]
