Excellent summary, Ilari. Bookmarking this to copy into the relevant HPKE WG issue when that group is formed.
For the record, I am also in favor of this change. On Fri, Mar 21, 2025 at 12:50 AM Ilari Liusvaara <[email protected]> wrote: > On Fri, Mar 21, 2025 at 10:34:54AM +0700, Orie wrote: > > > > Several folks have raised concerns about HPKE Auth Mode, and recent chats > > at IETF 122 have convinced me to test the waters on removing support for > > auth mode in JOSE HPKE. > > > > https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/32 > > > > This PR removes auth mode and auth psk mode. > > > > Do you think we should remove support for HPKE Auth Mode from JOSE HPKE? > > > Summarizing the known security considerations: > > 1) HPKE Auth is very broken with Key Encryption. > > The actual message is not authenticated. Therefore an attacker that > somehow compromises the CEK can replace the actual message with an > arbitrary one. Furthermore, the attacker can drop all the recipients > except the victim, leaving no trace of an attack. > > The attacker encrypts arbitrary protected headers, payload and JWE > AAD with the compromised CEK and replaces the message fields with the > results. > > I think this is such a footcannon that HPKE Auth for Key Encryption > should definitely be removed. > > This attack is not possible with Integrated Encryption, because the > authentication does cover the actual message. > > > 2) HPKE auth is vulnerable to KCI. > > Even with Integrated Encryption, an attacker that has compromised the > private key of the victim can spoof arbitrary messages from arbitrary > sources. > > Attacker computes AuthEncap() DH(skS, pkR) as DH(skR, pkS) and pk(skS) > as pkS. > > Funkily enough, it seems that attacker somehow learning DH(skR, pkS) > (equivalently DH(skS, pkR)) allows arbitrary messages to be forged > from the given sender to the given recipient. > > > This can be very bad in practice. For example with device firmware, it > is much worse to compromise integerity than to compromise > confidentiality, and it is very difficult to protect the keys from > getting compromised. Doing this safely pretty much requires using > signatures. > > This might be a big enough footgun to completely remove HPKE Auth mode > from JOSE-HPKE. > > > 3) Mixing HPKE Sender and Recipient roles may be unsound. > > HPKE does not guarantee it is sound (attacks seem unlikely, but it has > not been proven there are none) to use the same key in both sender > and recipient roles (unlike things like using the same key with any > ciphersuite it is compatible with). Furthermore, JWK has no facility to > constrain key to only HPKE recipient/sender role, causing operational > issues. > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
