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]
