Re: [COSE] [jose] Fwd: New Version Notification for draft-reddy-cose-jose-pqc-kem-00.txt

[Ilari Liusvaara <[e-mail]>]

On Tue, Mar 05, 2024 at 07:32:17AM -0600, Orie Steele wrote:
> Draft looks very familiar after have spent so much time with HPKE.

The mechanism should look very similar to ECDH-ES. Not similar at all
to HPKE. In fact, it takes one very small change and relabeling things
to turn ECDH-ES into KEM.


> Having different direct mode alg values for ML-KEM and HPKE that are both
> basically telling you to look an enc... Is wasting registry space.
> 
> alg: dir, is sufficient.

No, it is not. In JWE, alg:dir is REQUIRED to be symmetric AEAD.

Neither this nor HPKE is symmetric AEAD.

Even if I think that JWE does not formally ban interference between alg
and enc (the current fully-specified algorithms draft does ban it), it
is is extremely bad idea to have such interference.

 
> The documents that register the new enc modes can explain why.

I do not think that JWE even allows new enc modes.


> I think it would be better to see ML-KEM suites in HPKE, instead of seeing
> duplicates.

On duplicates, all the current proposed HPKE stuff is essentially
duplicates.

The only things HPKE can do that JOSE/COSE can not is exactly the
stuff that is not supported in present HPKE in JOSE/COSE stuff
(compact curves and the prototype PQ hybrid).

Yes, there are some KDF stuff as well, but I don't think there is any
security relevance.

But see below for very radical idea.


> There will also be different security issues, without the HPKE context and
> key commiting, etc...

The security issues of KEMs will be pretty much the same as security
issues of ECDH-ES.


> With hydrids on the horizon... it's a mistake to register hydrids twice...
> Once for HPKE and once for standalone.
> 
> I think we should use HPKE until there is reason not to use it.
> 
> Is this draft motivated by implementers who could not use HPKE?

HPKE in COSE/JOSE is certainly simpler than ECDH-ES.

Very radical idea would be to deprecate ECDH algorithms for HPKE.


> Are there critical use cases that multiple vendors need to support that
> only work without using HPKE?

One needs pure ML-KEM-1024 for CNSA 2.0. I don't know if HPKE will add
that or not.




-Ilari