Re: [COSE] HPKE for COSE

Hi Hannes,

See inline

Cheers,
John

From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Date: Tuesday, 9 November 2021 at 07:57
To: John Mattsson <john.mattsson@ericsson.com>, cose@ietf.org <cose@ietf.org>
Cc: Russ Housley <housley@vigilsec.com>, Brendan Moran <Brendan.Moran@arm.com>
Subject: RE: [COSE] HPKE for COSE
Hi John,

Thanks for looking at the document.

My responses are below:

From: John Mattsson <john.mattsson@ericsson.com>
Sent: Tuesday, November 2, 2021 2:27 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; cose@ietf.org
Cc: Russ Housley <housley@vigilsec.com>; Brendan Moran <Brendan.Moran@arm.com>
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.

[John] Yes, I know the motivation for introducing HPKE in general, I think I actually suggested parts of the text you cite :)

I personally think introducing HPKE in COSE is a great idea and I will support adoption of this document, but I still think the draft should motivate shortly why introducing HPKE in COSE is a good idea. I also think the draft should also give some info to readers why they should use e.g. "HPKE/P-256+HKDF-256" or "ECDH-ES + HKDF-256" and if there are any differences. I don't think that is not obvious to most readers. I think many users would be a bit confused by two very similar key echange algorithms and wonder if there are any big differences.

What you write about code reuse between different protocols is a good motivation. I think you should add that to the document. You could also add something similar to what I wrote in the other email that this allows COSE to automatically use all future HPKE KEMs including PQC KEMs.

- 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.

[John] I think it would be if the draft added something like the above text to clarify the use case of encrypting once for several recipients. Document should also shortly mention the privacy disadvantages, that an attacker can trivially see that the recipients got the same message.

- 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.

[John] I think it might be enough to clarify that the two layer CEK design is for encrypting once to several recipients.

- 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 <cose-bounces@ietf.org<mailto:cose-bounces@ietf.org>> on behalf of Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>>
Date: Monday, 25 October 2021 at 18:58
To: cose@ietf.org<mailto:cose@ietf.org> <cose@ietf.org<mailto:cose@ietf.org>>
Cc: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>, Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>
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
COSE@ietf.org<mailto:COSE@ietf.org>
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.