Re: [jose] New Version Notification for draft-rha-jose-hpke-encrypt-02.txt

I have read this document and have a few comments.

In the Introduction it states "The motivation for standardizing a public key encryption scheme [...]". But, of course, *cough*, HPKE is not a standard and so doesn't standardise anything. If you look at the nits output it is also flagging this:
  ** Downref: Normative reference to an Informational RFC: RFC 9180
I'm not convinced that HPKE is a good fit for JOSE. For example, section 9.1.2 of RFC 9180 states:

"A detailed computational analysis of HPKE's Auth mode single-shot encryption API has been done in [ABHKLR20 <https://www.rfc-editor.org/rfc/rfc9180#ABHKLR20>]. The paper defines security notions for authenticated KEMs and for authenticated public key encryption, using the outsider and insider security terminology known from signcryption [SigncryptionDZ10 <https://www.rfc-editor.org/rfc/rfc9180#SigncryptionDZ10>]. The analysis proves that DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for all Diffie-Hellman groups specified in this document."

But this is factually incorrect. What the referenced paper actually states is that one of the 4 security notions it analyses, namely Insider-Auth security, is *not* achieved by HPKE and it is in fact infeasible to achieve in HPKE's DH-AKEM. I find it quite disturbing that an RFC would misrepresent the literature in this way.

Insider-Auth security is *extremely* important in the context of something like JOSE where there are multi-recipient messages. Without it, when Alice sends a message to both Bob and Charlie, Bob can then turn around and send a forged message to Charlie that looks like it came from Alice. This is not a minor security property, it is absolutely crucial to the notion of data origin authentication! My own (now expired due to lack of interest) draft defining an authenticated public key encryption mode for JOSE went to pains to prevent this kind of attack [1] because it is so crucial. The only way to prevent it in this draft as it stands would be to also sign the content, which renders the authentication redundant.

My understanding is that HPKE doesn't address this because HPKE was designed for MLS and MLS solves it at a higher level. But JOSE doesn't, so will have to do something else instead. If you got rid of the authenticated KEM variants from this draft, then the remaining unauthenticated DHKEM variants are so similar to ECDH-ES that I wonder why we need them?

-- Neil

[1]: https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04#section-2.1 <https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04#section-2.1> 

> On 22 Jan 2024, at 05:26, tirumal reddy <kondtir@gmail.com> wrote:
> 
> Hi all,
> 
> This revision of the draft https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt <https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt> addresses comments from Illari. 
> Further comments and suggestions are welcome.
> 
> Cheers,
> -Tiru
> 
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Mon, 22 Jan 2024 at 10:53
> Subject: New Version Notification for draft-rha-jose-hpke-encrypt-02.txt
> To: Michael B. Jones <michael_b_jones@hotmail.com <mailto:michael_b_jones@hotmail.com>>, Tirumaleswar Reddy.K <kondtir@gmail.com <mailto:kondtir@gmail.com>>, Aritra Banerjee <aritra.banerjee@nokia.com <mailto:aritra.banerjee@nokia.com>>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net <mailto:Hannes.Tschofenig@gmx.net>>, Hannes Tschofenig <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>, Orie Steele <orie@transmute.industries>
> 
> 
> A new version of Internet-Draft draft-rha-jose-hpke-encrypt-02.txt has been
> successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
> 
> Name:     draft-rha-jose-hpke-encrypt
> Revision: 02
> Title:    Use of Hybrid Public-Key Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)
> Date:     2024-01-22
> Group:    Individual Submission
> Pages:    16
> URL:      https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.txt <https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.txt>
> Status:   https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/ <https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/>
> HTML:     https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.html <https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.html>
> HTMLized: https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt <https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt>
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-rha-jose-hpke-encrypt-02 <https://author-tools.ietf.org/iddiff?url2=draft-rha-jose-hpke-encrypt-02>
> 
> Abstract:
> 
>    This specification defines Hybrid public-key encryption (HPKE) for
>    use with Javascript Object Signing and Encryption (JOSE).  HPKE
>    offers a variant of public-key encryption of arbitrary-sized
>    plaintexts for a recipient public key.
> 
>    HPKE works for any combination of an asymmetric key encapsulation
>    mechanism (KEM), key derivation function (KDF), and authenticated
>    encryption with additional data (AEAD) function.  Authentication for
>    HPKE in JOSE is provided by JOSE-native security mechanisms or by one
>    of the authenticated variants of HPKE.
> 
>    This document defines the use of the HPKE with JOSE.
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose