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

[Thad Thompson <[e-mail]>]

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