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

[Dennis Jackson <[e-mail]>]

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. FWIW, it's not the case that 2-party insider-auth implies 
multiparty insider auth - so its pretty irrelevant here.

> 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).
On the RFC side, it does not actually claim any specific properties 
except those defined in the paper, so thus far these are compatible. 
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).

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

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.

Best,
Dennis

>
> -- Neil
>
>> On 8 Apr 2024, at 19:11, Thad Thompson <[e-mail]> wrote:
>>
>> Hey Neil,
>> For what it's worth, as an Internet rando (non-cryptographer) 
>> implementing a scheme very similar to the one you're suggesting, my 
>> understanding from the RFC was that the target security property of 
>> KEM authentication rather explicitly only covers two parties:
>>
>> > 5.1.3.  Authentication Using an Asymmetric Key
>> >
>> >   This variant extends the base mechanism by allowing the recipient to
>> >   authenticate that the sender possessed a given KEM private key.  This
>> >   is because AuthDecap(enc, skR, pkS) produces the correct KEM shared
>> >   secret only if the encapsulated value enc was produced by
>> >   AuthEncap(pkR, skS), where skS is the private key corresponding to
>> >   pkS.  In other words, at most two entities (precisely two, in the
>> >   case of DHKEM) could have produced this secret, so if the recipient
>> >   is at most one, then the sender is the other with overwhelming
>> >   probability.
>>
>> Am I not understanding that correctly? I assume that limitation is 
>> part of the reason MLS relies on asymmetric signatures for 
>> authentication.
>>
>> However, I would agree that the limitations of KEM based 
>> authentication feel maybe a bit out of place. Besides the fact that 
>> it only proves authentication in a two-participant system, it also 
>> becomes fiddly when moving to PQ KEMs. You either wind up with a 
>> halfway 'quantum safe key exchange but NOT quantum safe 
>> authentication' scheme like Signal's PQXDH, or it is dropped 
>> entirely, like in X-Wing. In any case, it seems like the 
>> authenticated KEM modes in HPKE take up a large space in the standard 
>> for what turns out to be rather limited functionality with caveats. I 
>> wonder if HPKE 2.0 would include such modes at all?
>>
>> Cheers!
>> - Thad
>
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://mailman.irtf.org/mailman/listinfo/cfrg