[jose] Re: [COSE] Re: Fwd: New Version Notification for draft-reddy-cose-jose-pqc-kem-02.txt

[tirumal reddy <[e-mail]>]

Hi Illari,

Thanks for the review. Please see inline

On Tue, 9 Jul 2024 at 21:05, Ilari Liusvaara <[e-mail]>
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: <[e-mail]>
> > 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 <[e-mail]>, Aritra Banerjee <
> > [e-mail]>, Hannes Tschofenig <[e-mail]
> >,
> > Hannes Tschofenig <[e-mail]>
> >
> >
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>