Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

[Ilari Liusvaara <[e-mail]>]

On Mon, Jan 17, 2022 at 02:51:13PM +0000, Hannes Tschofenig wrote:
> Thanks for the detailed comments, Ilari.
> 
> Let me provide comments below:
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, January 17, 2022 12:19 PM
> To: Hannes Tschofenig <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01
> 
> On Mon, Jan 17, 2022 at 09:36:34AM +0000, Hannes Tschofenig wrote:
> >
> > with draft-ietf-cose-hpke-00 I have submitted the draft version that
> > was subject to the working group call for adoption. John and Goeran
> > provided feedback already and suggested to re-use the algorithm
> > registry created by HPKE.
> >
> > In https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt
> > the proposed -01 version can be found.
> >
> > Please have a look at it and let me know if the proposed changes are
> > inline with the suggestions.
> 
> In can make little sense of the way HPKE is used.
> 
> - Why are the symmetric and asymmetric parts of HPKE split into two
>   different layers? The whole point of HPKE singleshot mode is to
>   combine them.
> 
> [Hannes] We are adding another layer to allow for additional use cases.
> The use case is to encrypt a payload once for different recipients.

With HPKE, one could do that with two-layer structure (and even mix it
with other modes):

- Layer 0: Message
  - Layer 1: HPKE (CEK for recipient1)
  - Layer 1: HPKE (CEK for recipient2)
  - Layer 1: AES-KW (CEK)
    - Layer 2: ECDH-ES (KEK for recipient3)
  - Layer 1: AES-KW (CEK for recipient4)

That encrypts the message only once, for four recipients:

- recipient1 and recipient2 use HPKE (asymmetric).
- recipient3 uses ECDH-ES (asymmetric)
- recipient4 uses AES (symmetric).

> - The layer 1 algorithm is specified as COSE encryption algorithm,
>   but for actually performing the encryption/decryption, one needs
>   HPKE AEAD ID.
> 
> [Hannes] Layer 2 uses the KEM algorithms from Section 7.1 of the HPKE spec:
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.1
> 
> Layer 1 uses the COSE algorithms instead of the algorithms in Section 7.3 of the HPKE spec
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.3
> 
> 
>   * How is the mapping between the two done?
>   * If new AEAD is added to HPKE, does one also have to register COSE
>     algorithm for it?
> 
>   Embedding the registry would mean 5 byte algorithm identifiers, as
>   there is just not enough space with smaller ones (need continuous
>   block of 65534 (sic) algorithm ids).
> 
> 
> [Hannes] It is possible to re-use the AEAD ID values from the HPKE
> spec instead of the corresponding COSE algorithms. However, there is
> not much of variation between the AEAD algorithms in COSE vs. the HPKE
> spec.
 
However, using COSE algorithms requires implemntation to translate those
into HPKE algorithms. This is because key derivation depends on HPKE
algorithm ID.

> - Recipients at layer 1 are specified as one-or-more. AFAICT, more than
>   one recipient here makes absolutely no sense.
> 
> [Hannes] It makes sense if you consider the use of firmware encryption.
> There, you want to have one CEK to encrypt the firmware image but multiple
> recipients.

It seems that Layer1 is ciphertext and Layer2 is encapsulated key.

So using multiple recipients at this layer would seem to correspond with
trying to use multiple encapsulated keys with the same ciphertext. At
best this produces decryption errors. At worst, it produces corrupt
plaintext.

(HPKE does have multishot mode where the same encapsulated key is used
with multiple ciphertexts.)
 
> - The algorithm ID at layer 2 needs new registrations to take advantage
>   of new HPKE algorithms. This especially inclures KEMs, which are one
>   of the most important extension points (post-quantum!).
> 
> [Hannes] By re-using the HPKE registry the idea was to re-use new KEMs
> as they come along.

Oh, the algorithm ID is HPKE KEM id. However, there is KDF id too.

For the present KEM algorithms, one could just match the KDF
(16 => 1, 17 => 2, 18 => 3, 32 => 1, 33 => 3), but this might not work
with future KEMs.

E.g., suppose Kyber v3.02 (one of the NISTPQC finalists) was added. 
What KDF does it use? None of the KDFs HPKE has (HKDF with SHA-2) are
in any way related to KDF Kyber internally uses (SHAKE256, which is
related to SHA-3).

> - Decomposing the keys at layer 2 needs code changes to support new
>   KEMs. Which likely can not be nontrivially decomposed anyway.
> 
>   However, currently HPKE does not have compact NIST curves, which
>   allows space saving via decomposition.
> 
>   Compromise might be to embed the registries (both may be jointly
>   embededed into 5 byte algorithm identifier) and have special values
>   for decomposed stuff (and shorthands for X25519/X448).[1]
> 
>   If both KEM and KDF can be sepcified, the KDFs SHOULD be matched.
> 
> [Hannes] There is obviously a downside to the re-use of the HPKE
> registry, as you point out. Splitting the registry into two appears
> quite complex to me. Adding new KEMs will, of course, require code
> changes. We should indeed think carefully whether this registry re-use
> offers enough benefits to do it.

Well, yes, there are tradeoffs:

- Special processing like compressing keys requires special-casing
  codepoints.
- Reusing the registry means COSE does not have to deal with
  registration requests. :-)

(Add compact NIST curves to HPKE, and then one does not have to deal
with key compression anymore.)

And then HPKE support might be shipped as library, which can change
indepedently of main application, in order to add new algorithms.

> - HPKE is different enough that I think both new kty and a new
>   operational mode are justified (I can make very little sense of
>   existing operational modes).
> 
> [Hannes] We are currently only using the base mode from the HPKE
> spec and utilize the COSE capabilities for authentication. The
> kty is used to describe the encapsulated key and there is no
> difference in the keys.

Actually, I got an idea that one could use OKP for raw HPKE
encapsulated keys, and other types for compressed encapsulated
keys (one probably only ever wants to compress P-256/P-384/P-521
encapsulated keys). And this would be independent of HPKE KEM
used.

One problem with that is the OKP crv parameter makes absolutely no
sense in such context. And it would not be quite as compact as
C509-style compression with special-case algorithm identifiers.

> - Doing HPKE with two layers with cose_encrypt, easily extends to
>   doing HPKE in cose_encrypt0: The only difference is directly operating
>   on the plaintext instead operating on the CEK. The limitation is
>   only having one recipient.
> 
> [Hannes] If the group wants a variant of COSE-HPKE that supports
> hybrid public key encryption for a single recipient only then I will,
> of course, do it. However, it is not clear to me whether this few
> additional bytes justify the extra variant. More variants = more
> complexity.

Well, OTOH it seems to be pretty trivial to do. And yes, it is
very few bytes saved, rough guess would be a dozen or so.


-Ilari