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

[Ilari Liusvaara <[e-mail]>]

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.

- The layer 1 algorithm is specified as COSE encryption algorithm,
  but for actually performing the encryption/decryption, one needs
  HPKE AEAD ID.

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

- Recipients at layer 1 are specified as one-or-more. AFAICT, more than
  one recipient here makes absolutely no sense.
  
- 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!).

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

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

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



[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