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

[Neil Madden <[e-mail]>]

On 8 Apr 2024, at 20:21, Dennis Jackson <ietf=[e-mail]> wrote:
> On 08/04/2024 19:48, Neil Madden wrote:
> 
>> I feel that people are getting a bit side-tracked here. Neither the HPKE RFC nor the erratum report mention either JOSE or multiple recipients. I bought that up in reply to another message as an example of *an* issue that can occur due to lack of Insider-Auth security.
> That's fair, but I do think its material in assessing the importance of the errata.
> 
Why do you need to "assess the importance" of the erratum? Either it's valid or it's not. 
> 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.

>> The issue under discussion is whether the RFC 9180 fairly characterises the security analysis that it cites. The RFC says HPKE "fulfills these notions", whereas the paper it cites says the following (section 5.1):
>> 
>> [...] 
>> 
>> Thus, HPKE does *not* fulfil this notion of security and shouldn't imply that it does. That's it. That's the erratum. Send tweet.
> That's a fairly ungenerous reading of the RFC and the paper. 
> 
> On the paper's side, they write: 
> 
>> 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).

This is in the context of AKEM security. They define the notion for APKE security.

> On the RFC side, it does not actually claim any specific properties except those defined in the paper, so thus far these are compatible.

"[T]hose defined in the paper" includes Insider-Auth security!

> 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.
> I'd also point out that insider security is not an especially well defined term, with nearly every paper using a different formulation in terms of 2 vs multiparty, malicious vs compromised       key registration, which parties can be compromised, etc... To quote from SigncryptionDZ10: 
> 
>> The signcryption literature is currently confused as to which of these models best represents multi-user insider confidentiality
This is about confidentiality. The cited paper defines the terms it uses formally.
> 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?

-- Neil