Hi Illari, Please see inline
On Tue, 23 Jan 2024 at 21:46, Ilari Liusvaara <[email protected]> wrote: > 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". > Okay. > > This is completely new kind of mode in JWE. I don't see any need to > explicitly name it. > I will say it is a single recipient setup. In this case, the shared secret established through HPKE will generate the content encryption key (CEK) and encrypt the plaintext. In this setup, JWE compact serialization must be used. This way, it will be clear when to use JWE compact serialization.. > > > > 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. > It is HPKE usage in a multiple-recipient setup. In this case, the shared secret established through HPKE will wrap the CEK. In this setup, JWE serialization must be used. > > > > > 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? > Not that I am aware of. > > Supporting that would require somewhat annoying hacks. > Okay. > > > > > 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). The deadlock can be prevented by invoking the SetupBaseS to get the HPKE context and HPKE enc. The HPKE context is then used to call Seal function with aad and pt as parameters. It would prevent the deadlock. I added the following text for clarity: In JWE Compact Serialization, the Single-Shot APIs specified in Section 6 of [RFC9180] for encryption and decryption cannot be used. This is because they require an 'aad' parameter, which takes the Encoded Protected Header comprising 'ek' as input. > > > > > > 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. > What do you mean by duplicating things like "zip" for compact 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. > Got it, Thanks. > > > > > - 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. > Yes. > > > > > - 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. > Got it. > > > > > - 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>. > Thanks for the clarification. Updated the draft to say that the SetupBaseS function will be called with the default value of an empty string for the 'info' parameter. -Tiru > > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
