Hi Illari, Thanks for the review. Please see inline
On Tue, 9 Jul 2024 at 21:05, Ilari Liusvaara <[email protected]> wrote: > On Tue, Jul 09, 2024 at 05:00:52PM +0530, tirumal reddy wrote: > > Hi all, > > > > Revised draft > > https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-kem-02.html > addresses > > comments from the WG. > > Further comments and suggestions are welcome. > > > > ---------- Forwarded message --------- > > From: <[email protected]> > > Date: Mon, 8 Jul 2024 at 20:11 > > Subject: New Version Notification for > draft-reddy-cose-jose-pqc-kem-02.txt > > To: Tirumaleswar Reddy.K <[email protected]>, Aritra Banerjee < > > [email protected]>, Hannes Tschofenig <[email protected] > >, > > Hannes Tschofenig <[email protected]> > > > > > > A new version of Internet-Draft draft-reddy-cose-jose-pqc-kem-02.txt has > > been > > successfully submitted by Tirumaleswar Reddy and posted to the > > IETF repository. > > > > Name: draft-reddy-cose-jose-pqc-kem > > Revision: 02 > > Title: Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE > and > > COSE > > Date: 2024-07-08 > > Group: Individual Submission > > Pages: 19 > > > Some comments: > > Section 5.1. Key Derivation for JOSE: > > The inputs "PartyUInfo", "PartyVInfo", "SuppPubInfo" and "SuppPrivInfo" > are missing. Those should be just copied from JWA section 4.6.2. > I thought these parameters were not required (the current version of JOSE HPKE does not use them). I will update the draft to re-use the inputs. > > "CipherText" is not valid input to Concat KDF. There is no need to > bind ciphertext: ML-KEM is already IND-CCA and forwarding-resistant, > which is enough for any ordinary encryption. > > MAL-BIND-K-CT or MAL-BIND-K-PK would require security proof that > ML-KEM is safe to use in protocol. Which is not possible to prove, > because MAL-BIND-K-CT or MAL-BIND-K-PK adversary can just trivially > break all security. > It is added to provide the same level of security properties as the HPKE and Hybrid HPKE (draft-connolly-cfrg-hpke-mlkem). Both offer MAL-BIND-K-CT and MAL-BIND-K-PK, whereas ML-KEM only provides MAL-BIND-K-PK. > > > Section 5.2. Key Derivation for COSE: > > > Why does this not just use the RFC9053 COSE_KDF_Context? > > - The structure name conflicting with the existing RFC9053 structure is > sure to cause confusion. > Yes, added a new structure name. > - Why have PartyUInfo and PartyVInfo been removed? > I thought these parameters were not required, so I will add them back. > - The ciphertext is completely unnecressary (see above). > Please see the response above. > > > Section 6.1. Direct Key Agreement: > > "Both header parameters, "alg" and "enc", MUST be placed in the JWE > Protected Header." > > ... Is this intentional deviation from JWE? If it is, that should be > called out. > No deviation from JWE; I will update text for better clarity. > > > "The parameter "kem-ct" MUST include the output ('ct') from the > PQ-KEM algorithm, encoded using base64url." > > ... Any reason not to use the "ek" parameter from JOSE-HPKE? > Yes, I missed to publish the change to use "ek"; I will correct it in the next revision. > > (there are also references to "kem-ct" in section 6.2.) > I will remove it. > > > Section 7.1. Single Recipient / One Layer Structure: > > COSE only allows one algorithm per layer, but there are two algorithms > (bulk encryption and direct key agreement) so this design will not work. > > This needs to be done the same way as ECDH-ES is used in COSE: Have bulk > encryption in layer0, and Direct Key Agreement in layer1. > We are following the same approach specified for ECDH-ES in COSE (Section 8.5.4 of RFC9052 and COSE HPKE) > > > Section 7.2. Multiple Recipients / Two Layer Structure: > > "and encrypted CEK in the encCEK structure" > > ... RFC9052 defines COSE_recipient to have "ciphertext" field for the > layer ciphertext (which is the key wrap output in this case). > Yes but I see COSE HPKE uses encCEK structure. > > > Then another way to do the same thing is to stick bulk encryption in > layer0, Key Wrap in layer1 and Direct Key Agreement in layer2. Using > Key Agreement with Key Wrap just saves some space. > > > Section 8. JOSE Ciphersuite Registration: > > What KDF hash do those algorithms use? > > The most aligned choice would be KMAC256 (as in NIST SP800-56Cr2), > using 131 (the spec has off-by-one goof) byte all-zeroes salt and > H_outputBits=L. > Yes, KMAC256 sounds good. > > > Section 9. COSE Ciphersuite Registration: > > Same as above, what KDF hash do those algorithms use? And the most > aligned choice is the same. > In case of COSE, HMAC with SHA-256 can be used as KDF. -Tiru > > > > > -Ilari > > _______________________________________________ > COSE 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]
