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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
