[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 08, 2024 at 08:11:51PM -0700, Les Hazlewood wrote:
> Thank you Orie, your last two replies are really helpful!
> 
> If flexibility and some degree of future proofing are desired, without an
> explosion of registration permutations, would it make sense to support the
> KEM and HKDF identifiers as separate header parameters?  For example:
> 
> "alg": "HPKE"
> "kem": "P256"
> "kdf": "HKDFS256"
> "enc": "A256GCM"
> 
> Then these would be pluggable as desired, so long as strength requirements
> are maintained between inputs/outputs.
> And the number of registrations for each respective header would be easily
> constrained to have a 1:1 correlation with the 3 functions in RFC 9180
> (KEM, KDF, AEAD triplet), as well as those in
> https://www.iana.org/assignments/hpke/hpke.xhtml
> 
> I'm not sure if this opens a can of worms or not, but it seems relatively
> elegant on the surface.  Thoughts?

There was an explicit decision to use ciphersuites instead of doing
that kind of thing (old versions of HPKE in COSE essentially did work
like that).

As far as I can see, that decision was driven by interop and "strength
matching" concerns.

My view of "strength matching" is strictly about efficiency: Using
resources to fortify something that is not the bottleneck wastes those
resources. However:

- It is not acceptable to artificially weaken things to "match" security
  of others.
- "X bits of security" arguments can be extremely misleading, especially
  if comparing confidentiality and authentication.




-Ilari