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

On 3 Apr 2024, at 00:13, Martin Thomson <mt@lowentropy.net> 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 <rfc-editor@rfc-editor.org>
>>> *Date:* 30 January 2024 at 10:24:00 GMT
>>> *To:* rlb@ipv.sx, karthikeyan.bhargavan@inria.fr, ietf@benjaminlipp.de, caw@heapingbits.net, irsg@irtf.org
>>> *Cc:* neil.e.madden@gmail.com, rfc-editor@rfc-editor.org
>>> *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 <neil.e.madden@gmail.com>
>>> 
>>> 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
>> CFRG@irtf.org
>> https://mailman.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg