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". 2) Similarly, multiple places refer to "Key Agreement with Key Wrapping". The mode looks more what JWE calls "Key Encryption". The use of this mode is specific to JSON serialization, so references to "Key Agreement with Key Wrapping" should be replaced with "JSON serialization". 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. For compact serialization, my proposal was to put HPKE enc (raw, as JWE implicitly does base64url on it) into "JWE encrypted key". 4) The "zip" only has special effect in compact serialization, in JSON serialization it does normal JWE thing. And the decryption section could add parenthetical that the message is possibly compressed. 5) The aad construction should refer to step 14 of S5.1 of JWE, instead of whole S5.1 of JWE. 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. - HPKE KDF already includes ciphersuite, making AlgorithmID unnecessary. - PartyUInfo uses insecure copy, making it a footgun. - HPKE lacks sender/receiver symmetry, so PartyUInfo/PartyVInfo are unnecessary. 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. 7) There is no need to discuss what SealBase() and OpenBase() do internally. 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
