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

Hi Neil,

On 08/04/2024 11:27, Neil Madden wrote:

>     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.
>
>
> Can you please point to the text in the RFC that says this is 
> forbidden? From HPKE's point of view there are two entirely separate 
> HPKE instances that happen to be encrypting the same plaintext (the 
> DEK). I don't see any text that forbids this or warns of any dangers 
> at all, hence this erratum report.

HPKE doesn't support multiple receivers so HPKE's security analysis 
doesn't say anything about what happens if you try to build such 
functionality yourself.

All the HPKE RFC says is that each recipient can be assured of the 
sender of the DEK and its authenticity. Claims about ciphertexts 
encrypted with that DEK are completely outside the scope of HPKE.

I'm not sure what a warning could look like except a very generic 
warning that the security of a primitive does not imply the security of 
any primitive or protocol that builds on it. Admittedly, this is might 
be worth stapling to the front of every CFRG draft.

On the upside, if the folks in JOSE (or other WG) want a version of HPKE 
for multiple recipients with authenticity guarantees, that seems like 
good motivation for a new 'mHPKE' CFRG draft.

Best,
Dennis

>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg