Re: [COSE] HPKE for COSE

[Hannes Tschofenig <[e-mail]>]

Hi John,

Thanks for looking at the document.

My responses are below:

From: John Mattsson <[e-mail]>
Sent: Tuesday, November 2, 2021 2:27 PM
To: Hannes Tschofenig <[e-mail]>; [e-mail]
Cc: Russ Housley <[e-mail]>; Brendan Moran <[e-mail]>
Subject: Re: [COSE] HPKE for COSE

Hi Hannes,

- I am positive, I am very fond of HPKE in general, but I think the draft fails to answer the question why. Why is this useful for COSE? What is the benefit compared to using the currently defined Ephemeral-Static algorithms in COSE?

[Hannes] The answers to the question of why the IRTF needs to standardize another public key encryption specification (given that there are already many out there) is found in the HPKE specification. In the introduction the HPKE document says:

"

   Currently, there are numerous competing and non-interoperable
   standards and variants for hybrid encryption, mostly based on ECIES,
   including ANSI X9.63 (ECIES) [ANSI<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-ANSI>], IEEE 1363a [IEEE1363<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-IEEE1363>], ISO/IEC
   18033-2 [ISO<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-ISO>], and SECG SEC 1 [SECG<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-SECG>].  See [MAEA10<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-MAEA10>] for a thorough
   comparison.  All these existing schemes have problems, e.g., because
   they rely on outdated primitives, lack proofs of IND-CCA2 security,
   or fail to provide test vectors.

   This document defines an HPKE scheme that provides a subset of the
   functions provided by the collection of schemes above, but specified
   with sufficient clarity that they can be interoperably implemented.
   The HPKE construction defined herein is secure against (adaptive)
   chosen ciphertext attacks (IND-CCA2 secure) under classical
   assumptions about the underlying primitives [HPKEAnalysis<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-HPKEAnalysis>],
   [ABHKLR20<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#ref-ABHKLR20>].  A summary of these analyses is in Section 8.1<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-08#section-8.1>.
"

Could they have taken a different route instead of inventing yet another public key encryption scheme? I think so but it is not for me to decide this.

What mattered for us as a consumer off the technology is that we wanted to re-use code. Since HPKE is already used in TLS and MLS, there was plenty of code available.

A developer can still select to use a different public key encryption scheme, if they want. Hence, we are not imposing any restrictions on developers. For firmware encryption with SUIT, however, we care about interoperability and a small number of options. Hence, in SUIT there are only two mechanism specified at the moment, namely one based on AES-KW and the HPKE version.



- Are the CEK and the layer 1 needed? Layer 1 and 2 are two layers of key encapsulation on top of each other. Why not use the the KEM shared secret directly in COSE_Encrypt?

[Hannes] They are not needed but using this design provides a nice benefit: We can now use this for encryption of content that is shared with multiple parties at the expense of only a single additional encryption operation. In the draft we encrypt the CEK and then the CEK is used to encrypt the plaintext. Applied to firmware encryption, we can therefore encrypt a firmware image and use HPKE to share the CEK with many different recipients securely.



- Is the intention to reuse Encap(pkR) several times? If you want to reuse the same encapsulation several times it might be better to use the salt parameter in HPKE or the IV parameter in COSE_Encrypt. The requirements on these parameters would be much lower than on the CEKs that have very randomness requirements.

[Hannes] This was not the intention. If this is not clear, then I need to clarify this aspect.


- The IANA registration follow directly from the HPKE draft. Can we do something smarter here so that any registered HPKE KEM can be used in COSE? There are already new more ligthweight KEMs suggested that might be a better fit for COSE. We can also expect registrations of all of the NIST PQC KEMs.
https://datatracker.ietf.org/doc/draft-harkins-cfrg-dnhpke/

[Hannes] I will respond to the IANA aspect in my second email.


- Editorial. I would suggest the following changes:

OLD "defined in RFC 2630 [RFC2630]"
NEW "defined in CMS [RFC2630]"

[Hannes]. Will be fixed with the next iteration.

Ciao
Hannes

Cheers,
John

From: COSE <[e-mail]<mailto:[e-mail]>> on behalf of Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Date: Monday, 25 October 2021 at 18:58
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Russ Housley <[e-mail]<mailto:[e-mail]>>, Brendan Moran <[e-mail]<mailto:[e-mail]>>
Subject: [COSE] HPKE for COSE
Hi all,

We have just submitted the initial version of hybrid public key encryption (HPKE) for COSE with draft-tschofenig-cose-hpke-00

This document was produced based on a discussion in the SUIT working group where we use HPKE for firmware encryption. The believe is that HPKE can be a more generic mechanism useful for other applications beyond SUIT.

We would like to have an agenda slot at the next meeting to introduce this work to the group.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.