Hi Illari, Please see inline
On Mon, 22 Jan 2024 at 18:39, Ilari Liusvaara <[email protected]> wrote: > On Mon, Jan 22, 2024 at 10:56:01AM +0530, tirumal reddy wrote: > > Hi all, > > > > This revision of the draft > > https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt > addresses > > comments from Illari. > > Further comments and suggestions are welcome. > > > > Cheers, > > -Tiru > > > > ---------- Forwarded message --------- > > From: <[email protected]> > > Date: Mon, 22 Jan 2024 at 10:53 > > Subject: New Version Notification for draft-rha-jose-hpke-encrypt-02.txt > > To: Michael B. Jones <[email protected]>, Tirumaleswar > Reddy.K < > > [email protected]>, Aritra Banerjee <[email protected]>, Hannes > > Tschofenig <[email protected]>, Hannes Tschofenig < > > [email protected]>, Orie Steele <[email protected]> > > > > > > A new version of Internet-Draft draft-rha-jose-hpke-encrypt-02.txt has > been > > successfully submitted by Tirumaleswar Reddy and posted to the > > IETF repository. > > > > Name: draft-rha-jose-hpke-encrypt > > Revision: 02 > > Title: Use of Hybrid Public-Key Encryption (HPKE) with Javascript > Object > > Signing and Encryption (JOSE) > > Date: 2024-01-22 > > Group: Individual Submission > > Pages: 16 > > URL: > https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.txt > > Status: https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/ > > HTML: > > https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.html > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt > > Diff: > > https://author-tools.ietf.org/iddiff?url2=draft-rha-jose-hpke-encrypt-02 > > Reading the updated draft, I thought, okay, how badly did I screw it up? > > > 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. > > > 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). . > > 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. > > > 3) It is not possible to use "encapsulated_key" (which could be > shortened to "ek") in compact serialization. > Replaced "ek" with "encapsulated_key". > > 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). > > 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. > > And the decryption section could add parenthetical that the message is > possibly compressed. > Yes, added following text: If a "zip" parameter is included, the recipient will uncompress the decrypted plaintext using the specified compression algorithm. > > > 5) The aad construction should refer to step 14 of S5.1 of JWE, > instead of whole S5.1 of JWE. > Fixed. > > > 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 KDF already includes ciphersuite, making AlgorithmID unnecessary. Please point me to the relevant section in 9180 about KDF including ciphersuite. > - PartyUInfo uses insecure copy, making it a footgun. > Are you referring to any specific JOSE implementation which uses insecure copy ? > - HPKE lacks sender/receiver symmetry, so PartyUInfo/PartyVInfo are > unnecessary. > I don't get it, please elaborate. > > 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". > > > 7) There is no need to discuss what SealBase() and OpenBase() do > internally. > Yes, it can be removed. Cheers, -Tiru > > > Reiterating my earlier proposal as mapping between HPKE inputs/outputs > and JWE constructs (with fixes to aad construction): > > a) Compact serialization: > > HPKE public key <---> Converted public key. > HPKE private key <---> Converted private key. > HPKE plaintext <---> (possibly compressed) message. > HPKE enc <---> JWE encrypted key. > HPKE ciphertext <---> JWE ciphertext. > HPKE aad <---> As specified by step 14 of S5.1 of JWE. > HPKE info <---> (empty) > (empty) <---> JWE Initialization Vector. > (empty) <---> JWE Authentication Tag. > > b) JSON serialization: > > HPKE public key <---> Converted public key. > HPKE private key <---> Converted private key. > HPKE plaintext <---> CEK. > BASE64URL(HPKE enc) <---> Unprotected recipient encapsulated_key. > HPKE ciphertext <---> receipient JWE Encrypted Key. > HPKE aad <---> (empty) > HPKE info <---> (empty) > > > The slight misalignment between the two seems unavoidable. > > > > > -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
