Hi Ilari, Thank you for your review. Please see https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/95 which addresses most of your comments on Section 10.1. Regarding the remaining two comments: The guidance on limiting private key access to one piece of code is generic key management advice not specific to JOSE HPKE. Weak algorithm guidance is out of scope for this document; the HPKE IANA registry does not currently have a 'Recommended' column like TLS.
-Tiru On Tue, 19 May 2026 at 15:26, Ilari Liusvaara <[email protected]> wrote: > 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] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
