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

[Neil Madden <[e-mail]>]

On 8 Apr 2024, at 18:10, Dennis Jackson <ietf=[e-mail]> wrote:

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. 

Actually, it does as I’ve pointed out. The security analysis in https://eprint.iacr.org/2020/1499" rel="nofollow">https://eprint.iacr.org/2020/1499 includes the definition of Insider-Auth security, which HPKE lacks and which would protect against this. The paper very clearly says that HPKE doesn’t achieve this notion, but the HPKE RFC instead chooses to say the following:

—

A detailed computational analysis of HPKE's Auth mode single-shot encryption API has been done in [https://www.rfc-editor.org/rfc/rfc9180.html#ABHKLR20" class="xref" rel="nofollow">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 [https://www.rfc-editor.org/rfc/rfc9180.html#SigncryptionDZ10" class="xref" rel="nofollow">SigncryptionDZ10]. The analysis proves that DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for all Diffie-Hellman groups specified in this document.

—

It doesn’t “fulfil these notions” for Insider-Auth security; the RFC authors apparently felt it wasn’t important to mention that. I do. The current wording implies that HPKE satisfies all the security notions in the paper, when it doesn’t. 

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.

It would look like the text I suggested in my erratum report. Did you read it?

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.

IMO HPKE is not a good basis for that. I have no interest in HPKE in JOSE, but if people are going to try to do that (and they are) then they need to be aware of the security issues that can occur. They would be aware of them if the HPKE RFC didn’t misrepresent the security analysis it cites. 

— Neil