On Mon, May 18, 2026 at 06:43:00AM -0600, Brian Campbell wrote: > In discussions at (and around) IETF 125 regarding the prospective JOSE HPKE > PQ & PQ/T work, a very clear preference emerged among a rough consensus of > the WG, its chairs, and its responsible AD for being thoughtful and > intentional about the algorithm choices. This document, however, runs > somewhat contrary to that ethos and includes a few rather questionable > algorithms. Specifically, because JOSE does not have ChaCha20Poly1305 > content encryption, the ChaCha20Poly1305 Key Encryption variants in this > document are rather disjoint and borderline nonsensical. Why would one need > to do HPKE with ChaCha20Poly1305 to encrypt a key that will be used for AES > content encryption? If we as the standards creators don't have a compelling > answer, we shouldn't burden implementers and the JOSE ecosystem with more > unnecessary options. As such, I strongly suggest that > HPKE-4-KE and HPKE-6-KE be removed from this draft. Honestly, I'd like to > see the algorithm set pared down further but I can envision reasonable > arguments for and against the others in the document, so I realize that > doing so wouldn't be straightforward at all. However, I cannot see any > justification for having HPKE-4-KE and HPKE-6-KE so removing those two > seems like an easy win.
Agreed, I think that messages should only use single symmetric encryption algorithm, as: - The recipients must support the bulk algorithm anyway. - The security is limited to the weakest symmetric encryption used. For key agreement, the second is true, but not the first. While using bulk encryption algorithm to wrap Direct Key Agreement recipients is not an option in JOSE, the COSE_Encrypt code I wrote did just that (which I think is the only safe way to do what is requested). And then, section 10.1 seems to misinterpret HPKE section 9.2.2: - The prohibition of reusing keys across KEMs is about DeriveKeyPair(), which HPKE in JOSE does not use. While using the same key for multiple KEMs is currently not possible, (there are no cipher suites that would have different KEMs but keys that are compatible with each other) turns out there actual security concerns here: While there is no problem mixing traditional and compact EC KEMs (16 to 21), mixing X25519 (32) and X25519+Elligator (34) might cause problems. However, I have no idea why anyone would use Elligator with JOSE (as Elligator is for hiding ciphertexts, and JWE is a blatant ciphertext). - The caution (this should be safe, but is not proven to be so) about multiple modes maps to using the same key with and without psk_id, which is not even discussed. It has nothing to do with Integrated Encryption versus Key Encryption. - There is no similar caution about mixing HPKE cipher suites, implying that has been proven to be secure. Thus, there are no "unintended interactions or vulnerabilities between algorithms". Other issues with section 10.1: - Using HPKE and non-HPKE algorithms with the same key is not sound (but probably does not lead to disaster). There is no discussion about this. - The stuff about wrapping the same content encryption key makes no sense, since it seems to refer to IE/KE and there is no content encryption key in IE. Some other security considerations: - Algorithms that are considered too weak MUST NOT be used for encryption, as that would compromise confidentiality. - Each private key SHOULD be only be used by one piece of code, as having multiple pieces of code touch it increases exposure to leakage or misuse. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
