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

[Ilari Liusvaara <[e-mail]>]

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