On Tue, Jan 23, 2024 at 06:41:23PM +0530, tirumal reddy wrote: > > On Mon, 22 Jan 2024 at 18:39, Ilari Liusvaara <[email protected]> > wrote: > > > > 1) The draft in multiple places refers to "Direct Key Agreement". What > > it does is not DKA, but completely new kind of mode for JWE that > > directly encrypts the message with HPKE. Obviously JWE does not have > > existing term for that kind of mode! > > > > The use of this mode is specific to compact serialization, so references > > to "Direct Key Agreement" should be replaced with "compact > > serialization". > > > > It is a variation of Direct Key Agreement mode that not only generates the > CEK but also encrypts the payload. > I will update the draft to make it clear.
Direct Key Agreement in JWE has specific meaning. It is not acceptable to redefine that, even if "similar". This is completely new kind of mode in JWE. I don't see any need to explicitly name it. > > 2) Similarly, multiple places refer to "Key Agreement with Key > > Wrapping". The mode looks more what JWE calls "Key Encryption". > > > > It is similar to ECDH+AESKW, which also defines it as a Key Agreement with > Key Wrapping mode for wrapping or encrypting the CEK (see > https://datatracker.ietf.org/doc/html/rfc7518#section-4.6). No, it is Key Encryption, not Key Agreement with Key Wrapping. Both have specific meanings in JWE. > > The use of this mode is specific to JSON serialization, so references to > > "Key Agreement with Key Wrapping" should be replaced with "JSON > > serialization". > > > > CEK wrapping is also possible with compact JSON serialization. Are there usecases for that? Supporting that would require somewhat annoying hacks. > > 3) It is not possible to use "encapsulated_key" (which could be > > shortened to "ek") in compact serialization. > > > > This is because of cyclic dependency: To call HPKE SealBase(), you > > need the HPKE enc, but to get the HPKE enc, you need to call HPKE > > SealBase(). Deadlock. > > > > I don't get the deadlock, SealBase is invoked by using the recipient's > public key (pkR). More explicitly: 1) To get HPKE enc, you need to call HPKE SealBase(). 2) To call HPKE SealBase(), you need aad. 3) To get aad, you need all protected headers. 4) To get all protected headers, you need encapsulated_key. 5) To get encapsulated_key, you need HPKE enc. 6) Goto 1). > > For compact serialization, my proposal was to put HPKE enc (raw, as > > JWE implicitly does base64url on it) into "JWE encrypted key". > > > > Yes, it is already discussed in > https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt-02#section-6.1 > . > > > > > > > > 4) The "zip" only has special effect in compact serialization, in > > JSON serialization it does normal JWE thing. > > > > My understanding is the "zip" parameter is not specific to JSON compact > serialization; it can be used in both compact and JSON serialization. The issue is that with JOSE-HPKE, the normal JWE rules do not apply to compact serialization, but do apply to JSON serialization. This requires duplicating things like "zip" for compact serialization, but not for JSON serialization. > > 6) Using strcture from S4.6.2. of JWA for info is nonsensical. > > > > That strcture is of completely wrong type: It is KDF input, not KDF > > context. HPKE has its own internal KDF. > > > > And that is not the only problem: > > - HPKE uses multiple key data lengths for even one ciphersuite, making > > key data length ill-defined. E.g., AES-128-GCM uses both 128 and 96. > > > > I don't see multiple key data lengths specified in Section 7.3 of > https://datatracker.ietf.org/doc/rfc9180/ for AES-128-GCM. HPKE uses the same external context to invoke KDF twice, once for key and once for base nonce. Section 5.1, Look for LabeledExpand(..., key_schedule_context, ...). For AES-128-GCM, the first is 128 bits, and the second is 96 bits. > > - HPKE KDF already includes ciphersuite, making AlgorithmID unnecessary. > > > Please point me to the relevant section in 9180 about KDF including > ciphersuite. Section 5.1, the implicit "suite_id" parameter. > > - PartyUInfo uses insecure copy, making it a footgun. > > Are you referring to any specific JOSE implementation which uses insecure > copy ? No, JOSE specification itself uses insecure copy. Doing this kind of stuff securely is highly application-specific. > > - HPKE lacks sender/receiver symmetry, so PartyUInfo/PartyVInfo are > > unnecessary. > > I don't get it, please elaborate. The main purpose of PartyUInfo/PartyVInfo is to prevent A sending to B and B sending to A from using the same keys. HPKE does not have that problem. > > > > Furthermore, using info input causes problems with some HPKE > > implementations: > > > > - Some implementations do not allow specifying aad and info > > simultaneously. > > - Some implementations have 64 byte limit for info. > > > > I don't see any such restrictions imposed in the specification of OHAI > which uses "info". Some specifications just ignore the size limit and assume HPKE implementation can deal with it. It is just that it is not a bug if it does not. And unfortunately there is not even buggy software that does not implement practically needed features because RFCs don't require those. Mixing aad and info is worse, HPKE explicitly recommends implementations to not allow using both in Seal<mode>/Open<mode>. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
