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

[Neil Madden <[e-mail]>]

On 8 Apr 2024, at 07:58, Karthik Bhargavan <[e-mail]> wrote:
> 
> 
> Hello Neil,
>  
>> Are you quoting someone here, or is this your opinion? My own opinion (as the erratum reporter) is that RFC 9180 seriously misrepresents the security analysis it is supposed to be based on. At least in a JOSE context, that misrepresentation could lead to serious security vulnerabilities.
>> 
>> For example, suppose you use HPKE AKEM with JOSE to encrypt an OAuth access token to be consumed by two APIs: A and B (each with their own public keys). The lack of Insider Auth security means that when A receives an access token from a legitimate client, they can use it to create arbitrary forged access tokens to send to B.
> 
> I am not sure I fully understand this vulnerability. An authenticated HPKE ciphertext sent from S to A cannot be resent by A to B.
> Insider-Auth security typically only applies to KCI-style attacks. Could you explain a bit more what your concern is?
> I'd like to have a concrete sense of which security property is being violated here.

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. 

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