Identifying HPKE mode (mode_base, mode_auth...)

[laurencelundblade]

While this draft may not support anything but base mode, in the long run other modes must be supported, like mode_auth (which seems super useful) so there must be some indication of which mode.

My first thought is that it is part of the algorithm ID, but maybe it should be a separate protected header. Seems like we have to figure that out now.

[dajiaji]

We have defined COSE_HPKE_Sender structure for the next revision (draft-03) and I am going to suggest the following additions to the structure as a next step. Specifically, I was thinking of the need to specify the HPKE version information and support other HPKE modes other than the Base mode in the long run.

COSE_HPKE_Sender = {
    ? 0 => uint,        ; HPKE version (default: 1) *  ### new
    ? 1 => uint,        ; kem id
    2 => uint,           ; kdf id
    3 => uint,           ; aead id
    4 => bstr,           ; enc
    ? 5 => bstr,         ; sender public key (for Auth mode or AuthPSK mode) ** ### new
}

* Need to confirm the HPKE version can be expressed in uint.
** Need to discuss whether bstr or COSE_Key.

In my opinion, the HPKE mode (base, auth, etc.) should be negotiated between the sender and the recipient in advance on the application layer and we don't need to specify the mode information on the COSE-HPKE layer. However, there must be a way for the sender to send the sender's public key to the recipient.

What do you think about the idea?

[laurencelundblade]

Hi Daisuke,

There's no assumption of negotiation for anything to do with the algorithm in any part of COSE. The HPKE mode is a fundamental part of the algorithm so now that I've thought a bit more, I think it needs to be part of the algorithm identifier. COSE_ALG_HPKE_AES_128_GCM should be COSE_ALG_HPKE_BASE_AES_128_GCM and so on.

My understanding of algorithm IDs in COSE is that they are kind of like cipher suites. They specify the whole crypto protocol and building block algorithms used. There's no parameterization of them. I think this is a good design choice.

That probably means that COSE_HPKE_Sender should just carry what it needs to carry to represent the sender bytes. So probably no KEM, KDF and AEAD IDs. They should come from the algorithm identifier.

[laurencelundblade]

A further bit of framing -- imagine a COSE HPKE receiver that implements every standardized encryption method. If a sender creates a message using one of those standard methods, that message must contain all information necessary to decrypt it. There must not be reliance on an external protocol or negotiation. I believe that is the general way that COSE works today and how it should continue to work.

[dajiaji]

Hi @laurencelundblade

A further bit of framing -- imagine a COSE HPKE receiver that implements every standardized encryption method. If a sender creates a message using one of those standard methods, that message must contain all information necessary to decrypt it. There must not be reliance on an external protocol or negotiation. I believe that is the general way that COSE works today and how it should continue to work.

Yes, I agree with you and I have proposed to define a single alg=COSE_ALG_HPKE and define COSE_HPKE_Sender for other HPKE parameters (KEM, KDF and AEAD).

COSE_ALG_HPKE_AES_128_GCM should be COSE_ALG_HPKE_BASE_AES_128_GCM and so on.

Where is KEM and KDF information? HPKE cipher suite is the combination of KEM, KDF and AEAD.

If we try to put the HPKE cipher suite in COSE alg value, currently we have to register the combinations of 5 KEMS, 3 KDFS and 4 AEADS to IANA registry. The number of new alg values is 60. And If you want to put HPKE mode in algs as well, the number is 240...

In addition, the big problem is that we have to implement the mapping logic from the IANA COSE alg values to the IANA HPKE alg values in existing COSE libraries. If a new HPKE algorithm is defined, we have to register many alg values to the IANA COSE registry and update the existing COSE libraries. I don't want to do that. My proposal avoids these problems and can be implemented in ease.

[laurencelundblade]

My previous identifier examples were guesses and quite wrong. Apologies.

A more COSE-style integration of HPKE would have the AEAD algorithm ID in the body header parameters, not in the recipient cipher suite, so that fan out is reduced.

Note that COSE chose to skip HKDF-SHA-384 for ECDH. An integration of HPKE here could do the same.

FInally we can put PQ aside for now, as did the COSE authors, and just do DHKEM. We probably don’t really know what the PQ algorithm will be and probably don’t really want 4.

That gives a fan out of 2, not 60, DHKEM with two HKDFs.

It’s back up to 4 if basic mode and auth mode are used and psk modes are skipped. It seems like we can skip them to me.

My main comments will be on the mailing list; this comment here is that the combinatoric fan out is not necessary a big problem.

[dajiaji]

Note that COSE chose to skip HKDF-SHA-384 for ECDH. An integration of HPKE here could do the same.

Could you tell me the reason why the COSE WG chose to skip HKDF-SHA-384? Did the COSE WG exclude HKDF-SHA384 after considering the various use cases that might use COSE?

I believe that the COSE-HPKE layer should NOT assume a specific application; the COSE-HPKE layer should be generic.

That gives a fan out of 2,

Does this mean that DHKEM(X25519) and DHKEM(X448) will not be used in COSE-HPKE...?

And I think behind your answer "2" is the assumption that KDFs may be uniquely determined by KEMs, but this assumption also should not be made in the generic layer like COSE-HPKE because a KEM and a KDF are independent of each other .

Not 2 but at least 12 (4 kems and 3 kdfs) because X25519, X448 and HKDF-SHA384 should not be prohibited.

As Ilari mentioned on the COSE WG mailing list, to begin with, the basic premise is that it makes no sense to separate KEM (&KDF) and AEAD and map them to the COSE layer for definition.

[laurencelundblade]

Note that COSE chose to skip HKDF-SHA-384 for ECDH. An integration of HPKE here could do the same.

Could you tell me the reason why the COSE WG chose to skip HKDF-SHA-384? Did the COSE WG exclude HKDF-SHA384 after considering the various use cases that might use COSE?

I believe that the COSE-HPKE layer should NOT assume a specific application; the COSE-HPKE layer should be generic.

I don't really know why. I wasn't around for the discussion.

My guess is that the two options were considered sufficient, one for high-security with larger messages and compute times and the other for low-security. And if someone wanted medium they could go off and define it for themselves.

I don't think any particular use cases are built into this design choice.

That gives a fan out of 2,

Does this mean that DHKEM(X25519) and DHKEM(X448) will not be used in COSE-HPKE...?

I need to do more reading here to know for certain, but I think the DHKEM algorithm itself works with keys that use NIST, Edwards and other curves. In COSE's use of DH (similar to a KEM) there is no binding to the curve type of the key.

However, I think HPKE has chosen to mix in the curve of the keys in the meta information that is hashed into the output of HPKE. This is possibly to defend against some minor attacks that COSE's use of DH doesn't. That means in HPKE it might be true that there needs to more DHKEM identifiers, but that would be because of the overall HPKE design, not because of how DHKEM's work.

I'm not sure about this though.

And I think behind your answer "2" is the assumption that KDFs may be uniquely determined by KEMs, but this assumption also should not be made in the generic layer like COSE-HPKE because a KEM and a KDF are independent of each other .

Yes, KEM and KDF are of course independent, but the COSE design chose to bind ECDH (similar to a KEM) and KDF (plus key wrap too) into one identifier and made it through the whole RFC standardization process with that design.

Not 2 but at least 12 (4 kems and 3 kdfs) because X25519, X448 and HKDF-SHA384 should not be prohibited.

They are not prohibited. They are just not the primary ones initially registered.

As Ilari mentioned on the COSE WG mailing list, to begin with, the basic premise is that it makes no sense to separate KEM (&KDF) and AEAD and map them to the COSE layer for definition.

It's a design trade-off to me. To me the design HPKE chose for its APIs works, but the design COSE chose for ECDH also works and is worth considering.

[hannestschofenig]

Closed with version -03 (only support for base mode)