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

[Karthik Bhargavan <[e-mail]>]

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.

All my best,
Karthik



>
> 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
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://mailman.irtf.org/mailman/listinfo/cfrg
>