Hi Ilari,
At the IETF#113 in Vienna (see slide 9 in https://datatracker.ietf.org/meeting/113/materials/slides-113-cose-draft-ietf-cose-hpke-00) I suggested to remove Section 3.4 from the draft for the following reasons: * HPKE itself defines ways to add extra info into the key derivation function, and * HPKE incorporates various fields in the key derivation process already. If you are OK with it, I would delete Section 3.4 from the cose-hpke draft. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Friday, June 24, 2022 8:33 PM To: cose <[email protected]> Subject: [COSE] COSE-HPKE COSE_KDF_Context This came up when working on test implementation of COSE-HPKE: Section 3.2. HPKE Encryption with SealBase says: "This specification does not mandate the use of the info and the aad parameters." This looks to be very problematic for interop: Both info and aad must match on sender and receiver side for anything to work. Furthermore, external_aad only makes sense in layer 0, it is message-global property. external_aad at layer 1 should be empty. Section 3.4. Info Structure says: "This section provides a suggestion for constructing the info structure, when used with SealBase() and OpenBase()." Suggestion? This construction is interop-critical. And then there are issues with multiple fields of the proposed construction: - AlgorithmID: HPKE always includes algorithm info, so this is redundant. - PartyUInfo: HPKE base mode does not support authentication, so this needs to be pulled from enveloping structure if any. However: + Identity is not the same as kid, and suggestion to use kid as identity looks pretty strange to me. There are dedicated PartyU header fields anyway. + The construction talks about pulling values out of COSE_Sign_Tagged and COSE_Mac_Tagged. The problem is that these can have multiple signatures/MACs, and then it is unclear which one should be used. - PartyVInfo: + Same kind of using kid as identity as in PartyU case. + There are dedicated PartyV header fields. If those are in protected attributes, this is redundant as protected attributes are included anyway. - SuppPubInfo.keyDataLength: What on earth is one supposed to put here? HPKE has no coherent number of bits to extract from KDF (it currently always invokes KDF twice with different output lengths). + Using main key length would be unnecressary layering violation. + Obviously, HPKE always includes this info. - SuppPubInfo.other/SuppPrivInfo: These look like nice ways to ruin interop, but base RFC8152/RFC8152bis-algs already has those anyway. And then one thing to beware when signing/MACing HPKE ciphertexts is that none of the HPKE encryption algorithms are committing (GCM and Poly1305 are infamous for being non-committing). Which means that HPKE ciphertexts may decrypt with multiple keys to different plaintexts. Another minor concern is that if something goes wrong with key derivation in one-layer COSE-HPKE, the result is trying to decrypt the content with wrong key, which might be unpleasant if content is large. However, if content is large, overhead of two-layer structure (which does not decrypt anything large with potentially wrong keys) is minor. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
