Re: [COSE] Update to the COSE-HPKE draft and new use case (?)

[Hannes Tschofenig <[e-mail]>]

Hi Russ, Hi Ilari

Thanks for the comments regarding the COSE_Encrypt0. I have created PRs in https://github.com/cose-wg/HPKE/pulls

Regarding the algorithms and the ephemeral key I would like to send separate emails around.

Ciao
Hannes

-----Original Message-----
From: COSE <[e-mail]> On Behalf Of Russ Housley
Sent: Sunday, April 24, 2022 8:48 PM
To: Ilari Liusvaara <[e-mail]>
Cc: [e-mail]
Subject: Re: [COSE] Update to the COSE-HPKE draft and new use case (?)

Ilari:

Thanks for the review and keeping us honest about_encrypt0.  We were focused on the HPKE situation where there are multiple recipients.

Russ

> On Apr 22, 2022, at 12:48 PM, Ilari Liusvaara <[e-mail]> wrote:
>
> On Fri, Apr 22, 2022 at 11:54:59AM +0000, Hannes Tschofenig wrote:
>> Hi all
>>
>> I have created a PR to add the use case described below into the
>> COSE-HPKE draft:
>> https://github.com/cose-wg/HPKE/pull/5
>>
>> I briefly talked about this topic at the IETF meeting in Vienna.
>> Comments welcome!
>
> For this change specifically:
>
> 1) In section titled "HPKE Encryption with SealBase", there is this
> text:
>
> "IMPORTANT: For use in this specification, the plaintext "pt" passed
> into the SealBase is the CEK."
>
> While this is true in multi-recipient cose_encrypt case, it is not
> true in the single-recipient cose_encrypt0 case. Then the plaintext is
> the raw message.
>
> It seems this was forgotten to be changed to deal with the
> cose_encrypt0 case.
>
> Maybe something like:
>
> -----------------------
> IMPORTANT: For use in cose_encrypt, the plaintext "pt" passed into the
> SealBase is the CEK. The CEK is a random byte sequence of length
> appropriate for the encryption algorithm selected in layer 0. For
> example, AES-128-GCM requires a 16 byte key and the CEK would
> therefore be 16 bytes long. In case of cose_encrypt0, the plaintext
> "pt" passed into the SealBase is the raw plaintext.
> -----------------------
>
> 2) In section titled "HPKE Decryption with OpenBase", there is this
> text:
>
> "When decrypted, the result will be the CEK. The CK is the symmetric
> key used to decrypt the ciphertext in layer 0 of the COSE_Encrypt
> structure."
>
> Which again is not the case when using cose_encrypt0. Then the result
> will be the raw message.
>
> This seems to be similar text that has been forgotten to be changed to
> deal with cose_encrypt0 case.
>
> Maybe something like:
>
> -----------------------
> When decrypted, the result will be either the CEK (if using
> cose_encrypt), or the raw plaintext (if using cose_encrypt0). The CEK
> is the symmetric key used to decrypt the ciphertext in layer 0 of the
> COSE_Encrypt structure.
> -----------------------
>
> 3) The sections "Examples" -> "One Layer" and "Examples" -> Two Layer"
> both seem to have duplicate anchor "{#one-layer-example}".
>
> I think the anchor for the two layer example should be
> "{#two-layer-example}".
>
>
> 4) The one layer example expands the ephremeral key, but the two layer
> example does not. One would expect the two examples to be
> stylistically consistent.
>
>
> 5) The text about cose_encrypt0 says:
>
> "The sender MUST place the kid and ephemeral public key into the
> unprotected header."
>
> However, RFC8152 says:
>
> "If a key needs to be identified to the recipient, the enveloped
> structure ought to be used."
>
> While these two are not in normative conflict (MUST vs. ought), this
> still seems inconsistent.
>
>
>
> And then some comments on the spec in general:
>
> 6) The encoding of the encapsulated key produced by HPKE seems to be
> under-specified.
>
> HPKE gives octet string as encapsulted key. This apparently is placed
> into the ephremeral public key field in unprotected header. However,
> RFC8152 specifies this field to be cose_key, and it is not at all
> clear how to encode the octet string as cose_key. Especially what to
> fill as the kty field, which is mandatory in cose_key.
>
> Searching for existing RFC8152 construct to abuse, there is the
> "Symmetric" kty. Then the encapsulated key would look like:
>
> -1: {
>       /* kty => Symmetric */
>       1:4,
>       /* The raw encapsulated ciphertext. */
>       -1:h'04ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c8d12f18230208ebaa769f903917d59284526fd65a27ab5898913af10ed334398'
> }
>
>
> 7) I think that combining all the HPKE algorithms into one ciphersuite
> is a bad idea.
>
> While the KEM and KDF could be combined, trying to combine AEAD would
> lead into combinatorial explosion, or worse, into broken
> combinatorics, which are nasty to handle in any sort of sane way (see
> TLS 1.0-1.2 ciphersuites).
>
> Even with KEM and KDF combined, present HKDF would give 15 different
> ciphersuites.
>
> What I think should be done is just registering the HPKE AEADs as alg
> values (there are 3 of those currently), and then having OKP crv's for
> the combined KEM and KDF (there are 5 of those currently) in the key.
>
> That is, alg's like:
>
> - HPKE_AES_128_GCM (HPKE AEAD 1)
> - HPKE_AES_256_GCM (HPKE AEAD 2)
> - HPKE_ChaCha20Poly1305 (HPKE AEAD 3)
>
> And crv's like:
>
> - HPKE_P_256_HKDF_SHA256 (HPKE KEM 16 KDF 1)
> - HPKE_P_384_HKDF_SHA384 (HPKE KEM 17 KDF 2)
> - HPKE_P_521_HKDF_SHA512 (HPKE KEM 18 KDF 3)
> - HPKE_X25519_HKDF_SHA256 (HPKE KEM 32 KDF 1)
> - HPKE_X448_HKDF_SHA512 (HPKE KEM 33 KDF 3)
>
>
> This also mirrors the internal structure of HPKE: Mixing and matching
> AEADs is cryptographically kosher, while mxing and matching KDFs is
> not (and it is not possible to fix this due to shortcomings of the
> standard KEM interface).
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cose
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.