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

[Ilari Liusvaara <[e-mail]>]

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.

"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.


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.
- Why have PartyUInfo and PartyVInfo been removed?
- The ciphertext is completely unnecressary (see 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.


"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?

(there are also references to "kem-ct" in section 6.2.)


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.


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).


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.


Section 9. COSE Ciphersuite Registration:

Same as above, what KDF hash do those algorithms use? And the most
aligned choice is the same.




-Ilari