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

[Ilari Liusvaara <[e-mail]>]

On Mon, Jan 24, 2022 at 10:27:16AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> Thanks again for your input. A few responses below:
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, January 21, 2022 3:18 PM
> To: Hannes Tschofenig <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01
> 
> On Fri, Jan 21, 2022 at 01:15:50PM +0000, Hannes Tschofenig wrote:
> > Hi Ilari,
> >
> > You are again raising good points, namely
> >
> > 1) Should we convey the KEM ID, and KDF ID explicitly? I think so.
> 
> Well, I think that all HPKE algorithms should be supported in generic
> way, so that COSE does not have to deal with registering HPKE
> algorithms the second time.
> 
> [Hannes] I checked the TLS ESNI spec and there, if I understand
> correctly, the KEM ID is not explicitly communicated. The KDF ID is.

The KEM ID is in the public key structure.

... Hmm... One could actually omit the KEM id from ephemeral key,
unless some shortcut notation is used (since knowledge which KEM is
used is needed in order to uncompress the ephemeral key).

> > 2) If we do, where should this information go? You suggest to put them
> > into the COSE key (ephemeral key) structure. I would have thought that
> > the unprotected header would be more appropriate but I do not really
> > have a strong preference.
> 
> Well, for KDF id, one could stick it either inside ephemeral key
> structure, or the main headers.
> 
> [Hannes] What would be your preference?

That seems rather hairy question I am not sure about answer to...

> However, I think that one will run into cases where:
> 
> - KDF is implicit from KEM. E.g. KEM 17 is probably combined with
>   KDF 2.
> - KDF is not implicit from KEM. E.g. KEM 48 goes with KDF ???.
> 
> 
> [Hannes] In the ESNI spec, the KDF is explicitly communicated in
> the HpkeSymmetricCipherSuite structure. Regardless of whether some
> parameters can be communicated implicitly or explicitly, there is
> still the question about where the information has to go.

The idea behind implicit KDF is to derive it from the KEM. However,
that can not be assumed to always work. It works with the present KEMs,
but not necressarily with the future ones.

> (What is KEM 48?)

Oops, that should have been some presently unknown KEM that might not
have known internal KDF. E.g., Kyber512 v3.02 (which indeed does not
correspond with any known KDF).
 
And these KEMs that do not correspond to any known KDF are exactly the
ones where implicit KDF breaks down.

> > 3) Should we define a new kty id? If we place the KEM ID and the KDF
> > ID into the COSE key structure then I think it would be a good idea to
> > define a new kty id.
> 
> Well, there are not just HPKE encapsulated keys, HPKE also has public
> and private keys.
> 
> While reusing OKP for generic case would be possible (at cost of a few
> bytes, since crv will be pushed to 5 byte territory), I think new kty
> would be cleaner.
> 
> [Hannes] Having a new kty id parameter is OK for me. I am not sure
> what you mean by "HPKE also has public and private keys". The newly
> defined structure is supposed to communicate only the ephemeral public
> key

I mean, COSE_key can hold public or private keys for any algorithm
supported by COSE (with exception of HSS-LMS private keys).

HPKE does define format for its public and private keys.

> > IMHO we cannot use COSE_Encrypt0 because we need the recipient
> > structure, which is not present with the COSE_Encrypt0.
> 
> HPKE itself does not seem to need the recipient.
> 
> [Hannes] Here is how I understand COSE: " COSE_Encrypt0 is used when a
> recipient structure is not needed because the key to be used is known
> implicitly." So, the "recipient" structure is really only the name of
> the place where certain information is supposed to go. In my
> understanding we have to put the HPKE related info into the recipient
> structure.

My understanding is that the reason why one can not do ECDH-ES with
COSE_Encrypt0 is that ECDH-ES places the asymmetric stuff in different
layer as symmetric stuff, which means two layers minimum, but
COSE_Encrypt0 only allows one layer, so it just will not work.

But HPKE combines asymmetric and symmetric operations, which means it
maps most cleanly to one layer, which would fit COSE_Encrypt0.

> > You also seem to define new key formats. What prevents us from
> > re-using the existing COSE key formats? Section 13 of RFC 8152 defines
> > various ECC key formats and those could be re-used.
> > Since there is no compressed point format, we could add it.
> 
> One of the ideas I had for key compression was reusing the existing
> formats. And these are the cases where there is an obvious KDF to
> use.
> 
> Then there is question how generic HPKE keys should be presented.
> 
> [Hannes] If you also want to introduce support for compressed ECC
> keys then it makes sense to introduce a new kty id.

Actually, I only managed to save one byte with new kty id for the
compressed ECC case.

As to why it saves one byte, for P-256 EC2 uses:

A4 01 02 20 01 21 58 20 <32bytes> 22 F4/F5

And new kty with implicit KDF and C509-style compression would be
something like:

A3 01 xx 20 20 21 58 21 02/03 <32 bytes>

New kty id would make more sense for the cases that are not compressed
ECC.

> > I am also not sure why you talk about PQC algorithms. Neither COSE nor
> > HPKE define PQC algorithms. Do you think we should define them in this
> > document?
> 
> I am expecting that once NIST comes with PQC algorithm recommendations,
> those will be added to HPKE. And with generic HPKE algorithm support,
> those would be immediately usable in COSE.
> 
> [Hannes] To have them immediately usable the COSE fields have to exist
> where they should be placed. Why is the immediate usage so important?
> Most likely specification work will be needed by the HPKE authors as
> well since it is not just about adding an entry to the IANA registry.

Yes, HPKE needs to do specification work for that. But if there is a
generic way to dump random HPKE parameters into COSE message, then one
does not have to do any specification work in COSE.


-Ilari