Re: [CFRG] Fwd: [Technical Errata Reported] RFC9180 (7790)

[Karthik Bhargavan <[e-mail]>]

>
>
> HPKE only defines an interface for encrypting messages to a single
> recipient. Therefore standards like JOSE, which support multiple
> recipients, have to come up with an approach to support that. The obvious
> thing to do, and what is being proposed for JOSE, is to do what the
> existing ECDH-ES (ECIES) modes do: generate a random data encryption key
> (DEK) and use that to encrypt the message using an AEAD. Then run HPKE for
> each recipient to encrypt the DEK. You then concatenate all the wrapped
> DEKs and encapsulated keys with the ciphertext and send it.
>

That is an interesting use-case, but I don't see how you can use HPKE for
this.
The Encap/AuthEncap interface of HPKE does not allow you to encapsulate the
same key for two different recipients.
Indeed, as you note, doing so would be insecure and is forbidden.

One may certainly imagine a useful extension to HPKE that supports
multi-recipient KEM (mKEM) to provide multi-recipient HPKE, but in that
case you will definitely need more protections, either via plaintext
commitment or even stronger authentication properties about the group of
recipients etc. leading all the way to MLS.



>
> To decrypt, each recipient finds their encapsulated key, decapsulates it
> and decrypts the DEK and then uses that to decrypt the rest of the message.
>
> But the lack of Insider Auth security for HPKE makes this completely
> unsafe (when using an authenticated KEM) because when A receives such a
> message from S, she can use the DEK she recovers to create arbitrary forged
> messages to send to B that appear to come from S.
>
> This is why my own draft adding an authenticated version of ECIES to JOSE
> includes a commitment to the plaintext as associated data to the AKEM [1].
> I wrote a more detailed explanation of the problem and solution on my blog
> (after some discussion on this list) [2].
>
> Now, you can (I believe) do a similar solution in HPKE. However, the point
> is that nobody knows they *need* to do this because the HPKE RFC doesn’t
> mention it and only categorises the security weakness in terms of KCI,
> which is irrelevant to this attack. Both attacks are a consequence of a
> lack of Insider Auth security, however, and this lack in HPKE was known
> from the security analysis and should have been communicated.
>
> [1]:
> https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04#section-2.1
> [2]: https://neilmadden.blog/2021/02/16/when-a-kem-is-not-enough/
>
> — Neil
>