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

[Neil Madden <[e-mail]>]

> On 11 Apr 2024, at 16:21, Dennis Jackson <ietf=[e-mail]> wrote:
> On 08/04/2024 22:40, Neil Madden wrote:
> 
>> Why do you need to "assess the importance" of the erratum? Either it's valid or it's not. 
> If something is imperfectly worded,  it's typically marked "Hold For Document Update". 
> 
According to [1], “Hold for Document Update” means “[t]he erratum is not a necessary update to the RFC”. I would be disappointed in such an outcome. The examples given of that status are basically typos. 

The paragraph I quoted in the erratum is not even the full extent of what is wrong with the way the HPKE RFC cites this work. It goes on:

“ Further, [ABHKLR20 <https://www.rfc-editor.org/rfc/rfc9180.html#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.”

“ In summary, the analysis in [ABHKLR20 <https://www.rfc-editor.org/rfc/rfc9180.html#ABHKLR20>] proves that the single-shot encryption API of HPKE's Auth mode satisfies the desired message confidentiality and sender authentication properties listed at the beginning of this section”

Those properties are message confidentiality, export key secrecy, and sender authentication. Regarding sender authentication it says:

“ Analysis of the PSK, Auth, and AuthPSK modes defined in this document additionally requires verifying the sender authentication property. […] Generally, the authenticated modes of HPKE can be viewed and analyzed as flavors of signcryption [SigncryptionDZ10 <https://www.rfc-editor.org/rfc/rfc9180.html#SigncryptionDZ10>].”

That Signcryption reference is a book, chapter 2 of which says for Insider Auth security “the attacker is given the private key of the receiver, indicating that […] the signcryption scheme prevents a receiver from forging a signcryption ciphertext that purports to be from the sender.” That book in turn cites the classic paper [2], which says (bottom of page 9):

"Insider-security for authenticity implies non-repudiation "in principle". Namely, non-repudiation is certain at least when the receiver R is willing to reveal its secret key [...]. In contrast, Outsider-security leaves open the possibility that R can generate—using its secret key—valid signcryptions of messages that were not actually sent by S. In such a case, non-repudiation cannot be achieved no matter what R does."

These references quite clearly link the notion of Insider-Auth Security to the notion of non-repudiation, rather than merely to a notion of KCI. I discuss this further in [3].

So the HPKE RFC claims the following things:
That the ABHKLR20 paper “proves that […] HPKE’s Auth mode satisfies the […] sender authentication properties […]”
That that sender authentication property should be analysed under the notions of insider and outsider security from signcryption, which as I've discussed quite clearly includes the notion of Insider-Auth Security beyond KCI.
That ABHKLR20 proves that HPKE satisfies these notions from signcryption, which is at best only 75% true.
I’m sure it wasn’t deliberate, but however it happened, what is in the RFC as it stands is a misrepresentation of what the cited literature says. "Imperfectly worded" seems a pretty big understatement!

[1]: https://www.rfc-editor.org/errata-definitions/ <https://www.rfc-editor.org/errata-definitions/>
[2]: https://eprint.iacr.org/2002/046 <https://eprint.iacr.org/2002/046> 
[3]: https://neilmadden.blog/2021/02/16/when-a-kem-is-not-enough/ <https://neilmadden.blog/2021/02/16/when-a-kem-is-not-enough/> 
> 
>>> FWIW, it's not the case that 2-party insider-auth implies multiparty insider auth - so its pretty irrelevant here. 
>>> 
>> But we are talking about the contrapositive here: lack of 2-party insider-auth implies (obviously) lack of multi-party insider-auth. HPKE has neither.
>> 
>>> More significantly and immediately prior to the paragraph you're concerned about, the RFC details the attack on insider security presented in the paper at length (9.1.1). 
>> 
>> It describes a (related, to be sure) KCI attack. This is not the exact same thing, and it's in a section about KCI. As the paper says, KCI security is a relaxation of Insider-Auth security.
> As you wrote above, we're talking about the contrapositive. If KCI is violated, obviously Insider-Auth is too. 
> 
But KCI isn’t an issue in the attack I outlined. KCI attacks are a relatively small subset of Insider-Auth violations. KCI attacks, by their very name, presume that a key has been compromised. As the HPKE RFC itself says "sender authentication cannot be expected to hold in the Auth mode if the recipient private key skR is compromised". Given that many people assume that private key compromise is "game over anyway", this framing tends to let people think they can safely ignore that. But there are worse dragons than KCI.

>>> I agree the RFC could be better phrased, but do not think anyone could read the RFC and conclude that HPKE was proven to achieve Insider Security - let alone establish the type of Insider Security being discussed. Further, the paper lays out a clear attack on KCI in accessible language which is the material consequence of the lack of insider security anyway. 
>>> 
>> Firstly, KCI is not the only consequence of the lack of Insider-Auth, as discussed. Secondly, what are you trying to argue here? That the erratum is incorrect? That incorrect statements should remain in the RFC because... well, what exactly? Because a different paragraph in a different section almost says the right thing?
> I'm pointing out as imperfect as the sentence is, a reader is going to come away with the correct understanding. Minimally: 
> 
> HPKE is vulnerable to KCI attacks (and if the reader knows what Insider-Auth is, therefore doesn't have Insider-Auth).
But not that non-KCI attacks that violate Insider-Auth might be an issue. And if the reader is not familiar with Insider-Auth, they are certainly not going to be clued in by this RFC. 
> They need to read the referenced paper for the details of exactly what properties HPKE is proven to have, where they will find a clear statement it does not enjoy Insider-Auth.
Which contradicts what the RFC says. Why bother to write a security considerations section at all — just provide a list of references and let readers do the research themselves.
> As I said previously, if folks need a multi-party HPKE, that seems like a good thing for the CFRG to work on. 
> 
Given that HPKE was literally created for MLS (among others)[4], I don’t think it’s insane if people assume HPKE should be safe for multi-user communication.

[4]: https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38SyahhMF1Q4fBc/ <https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38SyahhMF1Q4fBc/> 

— Neil