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

[Hannes Tschofenig <[e-mail]>]

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.

- 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.



- 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.


- 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.



- 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.

- 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.


- 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.

Ciao
Hannes

[1]

E.g.:

- algid=-1 is like algid=0x00010010, but key is compressed like in C509.
- algid=-2 is like algid=0x00020011, but key is compressed like in C509.
- algid=-3 is like algid=0x00030012, but key is compressed like in C509.
- algid=-4 is alias for algid=0x00010020 (X25519 with SHA-256).
- algid=-5 is alias for algid=0x00030021 (X448 with SHA-512).


-Ilari
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.