Open point in Key Encapsulation section: how to convey L?

[DDvO]

How does the recipient of an HpkeCiphertext know/learn the value of the length L that the sender chose in its call of SendExportBase, to be re-used in the ReceiveExportBase call of the recipient?

[HBrock]

L is the output length of the KDF in byte and therefore the length of the secret derived from the HPKE. This secret will be used for MAC-based message protection using a MAC algorithm according to CMP Algorithms Section 6.2 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms-15#section-6.2 . Therefore, I think, L is specified by the length of the symmetric key to be used by the MAC algorithm. @Mike, is this understanding correct, or do you think we need to explicitly specify L in the HpkeCiphertext?

[HBrock]

Design team meeting minutes: I will add L to HpkeCiphertext and make enc optional. The client needs to send an HpkeCiphertext with kem, kdf, and L omitting enc in the first genm message. The server should accept the L an include into the HpkeCiphertext of the genp message. The client must check that the L from genp is at least as large as the security level of the chosen MAC algorithm.

[ounsworth]

I mentioned in #2 that if we include the overall transcript in the final key derivation (as recommended in the Kyber paper), then that maybe solves the problem of the client and server using different L values.

[HBrock]

I will add L to HpkeCiphertext.