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

[Benjamin Lipp <[e-mail]>]

Hi all,

I do see that the paragraph in the RFC is not optimally phrased, but I 
do not agree with the characterization and would like to suggest a 
differently phrased correction.

Responding to the note of the errata, “This is an important negative 
security result that should have been highlighted in the RFC”:

Sections 9.1.1 “Key-Compromise Impersonation”
https://www.rfc-editor.org/rfc/rfc9180.html#section-9.1.1
and Section 9.2.2 “AuthEncap/AuthDecap Interface” of the RCF
https://www.rfc-editor.org/rfc/rfc9180.html#section-9.2.2
do explicitly comment on the failure to provide Insider-Auth.

Furthermore, Section 5.1 of the Eurocrypt paper is explicit about the 
fact that Insider-Auth is _not_ defined for KEMs in this paper (and this 
is also mentioned in Section 9.2.2 of the RFC):

“Authenticity. […] We do not define an insider security notion because 
Insider-Auth security is infeasible both for the APKE construction used 
in HPKE (see Section 5.4), and the instantiation of AKEM proposed in 
HPKE (see end of Section 6.1)”

The sentences of the RFC touched by the errata are about the KEM DHKEM, 
and not about the entire HPKE: “The analysis proves that DHKEM's 
AuthEncap()/AuthDecap() interface fulfills these notions for all 
Diffie-Hellman groups specified in this document.”

A suggestion for a differently phrased correction in the errata:

“The paper defines three security notions for authenticated KEMs and 
four security notions for authenticated public key encryption, using the 
outsider and insider security terminology known from signcryption 
[SigncryptionDZ10]. The analysis proves that DHKEM's 
AuthEncap()/AuthDecap() interface fulfills the three KEM notions for all 
Diffie-Hellman groups specified in this document. An Insider-Auth notion 
is not defined for KEMs for the reasons discussed in Section 9.2.2.”
(referring and linking to Section 9.2.2 in the RFC).

And I would add a correction for the following paragraph, changing from

“Further, [ABHKLR20] proves composition theorems, showing that HPKE's 
Auth mode fulfills the security notions of authenticated public key 
encryption for all KDFs and AEAD schemes specified in this document, 
given any authenticated KEM satisfying the previously defined security 
notions for authenticated KEMs.”

to

“Further, [ABHKLR20] proves three composition theorems, showing that 
HPKE's Auth mode fulfills three security notions of authenticated public 
key encryption for all KDFs and AEAD schemes specified in this document, 
given any authenticated KEM satisfying the previously defined security 
notions for authenticated KEMs. HPKE's Auth mode does not fulfill the 
Insider-Auth notion as discussed in Section 9.1.1.”
(referring and linking to Section 9.1.1 in the RFC)

Best regards,
Benjamin

On 03.04.24 08:13, Neil Madden wrote:
> On 3 Apr 2024, at 00:13, Martin Thomson <[e-mail]> wrote:
>>
>> 
>>>
>>>  From my perspective, this erratum at least is not really errata-worthy.  It's great feedback on the document, but not strictly an error that needs correction. Oversights, omissions, and lost opportunities are to be expected.
> 
> 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.
> 
> This serious issue is not mentioned at all in RFC1980, but *is* clearly discussed in the linked security analysis. The RFC instead states (erroneously) that HPKE “fulfils these notions”. IMO it should never have been published with such a glaring mistake.
> 
> — Neil
> 
>>
>> The correct disposition for this sort of thing is "Hold for Document Update".
>>
>>> On Wed, Apr 3, 2024, at 07:46, Neil Madden wrote:
>>> Anyone know what’s going on with errata for HPKE? I reported this one
>>> in January and not heard anything about it. There appears to be 3
>>> errata on RFC 9180 that are in “reported” state, 2 of which date back
>>> to 2022. Is anyone looking at them?
>>>
>>> Regards,
>>>
>>> Neil
>>>
>>> Begin forwarded message:
>>>
>>>> *From:* RFC Errata System <[e-mail]>
>>>> *Date:* 30 January 2024 at 10:24:00 GMT
>>>> *To:* [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
>>>> *Cc:* [e-mail], [e-mail]
>>>> *Subject:* *[Technical Errata Reported] RFC9180 (7790)*
>>>>
>>>> The following errata report has been submitted for RFC9180,
>>>> "Hybrid Public Key Encryption".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid7790
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Neil Madden <[e-mail]>
>>>>
>>>> Section: 9.1.2
>>>>
>>>> Original Text
>>>> -------------
>>>>   A detailed computational analysis of HPKE's Auth mode single-shot
>>>>   encryption API has been done in [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].  The analysis proves that
>>>>   DHKEM's AuthEncap()/AuthDecap() interface fulfills these notions for
>>>>   all Diffie-Hellman groups specified in this document.
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>>   A detailed computational analysis of HPKE's Auth mode single-shot
>>>>   encryption API has been done in [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].  The analysis proves that
>>>>   DHKEM's AuthEncap()/AuthDecap() interface fulfills the notions of
>>>>   Outsider-CCA, Insider-CCA, and Outsider-Auth for all Diffie-Hellman
>>>>   groups specified in this document. It does not fulfill the notion of
>>>>   Insider-Auth defined in the paper.
>>>>
>>>> Notes
>>>> -----
>>>> The referenced paper defines four notions of security, Outsider-CCA, Insider-CCA, Outsider-Auth, and Insider-Auth. It proves that HPKE meets the first three, but, contrary to the current text of the RFC, it proves that it does *not* meet Insider-Auth security and that this is infeasible for HPKE. This is an important negative security result that should have been highlighted in the RFC.
>>>>
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". (If it is spam, it
>>>> will be removed shortly by the RFC Production Center.) Please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party
>>>> will log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC9180 (draft-irtf-cfrg-hpke-12)
>>>> --------------------------------------
>>>> Title               : Hybrid Public Key Encryption
>>>> Publication Date    : February 2022
>>>> Author(s)           : R. Barnes, K. Bhargavan, B. Lipp, C. Wood
>>>> Category            : INFORMATIONAL
>>>> Source              : Crypto Forum Research Group
>>>> Area                : N/A
>>>> Stream              : IRTF
>>>> Verifying Party     : IRSG
>>> _______________________________________________
>>> CFRG mailing list
>>> [e-mail]
>>> https://mailman.irtf.org/mailman/listinfo/cfrg
>>
>> _______________________________________________
>> CFRG mailing list
>> [e-mail]
>> https://mailman.irtf.org/mailman/listinfo/cfrg
>