With the draft as written, I'm not certain if there isn't a cross-protocol attack present when the same public key can be used both in direct mode and in key encryption mode, as the info field of HPKE is not used. Basically, I think with the draft as written I can take a direct mode encrypted message and reframe it as a key encryption mode message, now using the direct message as encryption key. Given that HPKE (and COSE counterpart) are not authenticated in the first place, I'm not certain whether this actually is exploitable, but I would recommend adding a domain separator between the two modes, most easily by having two prefixes chosen from a prefix-free set for the info field of HPKE, which would make such an out-of-context use impossible (and it works similar to how HPKE itself handles the info field, prefixing "HPKE-v1" to the info field before passing it to the KDF, in order to prevent future out of context attacks).
On Wed, Jun 18, 2025 at 10:58 AM Marco Tiloca <marco.tiloca= [email protected]> wrote: > Hi all, > > I have read the draft again and think that it is largely ready. > > Please find below some minor comments. > > Best, > /Marco > > ========== > > [Abstract] > > Given the first paragraph, isn't the last sentence of the abstract > redundant and possible to remove? > > > [Section 3.1] > > * It says: > > > The mode is 'mode_psk' if the 'psk_id' header parameter is present; > otherwise, the mode defaults to 'mode_base'. > > Suggested rephrasing: > > > The mode is 'mode_psk' if the 'psk_id' header parameter registered in > Section 7.2 and specified in Section 3.1.1 is present; ... > > Later in Section 3.1.1, it says: > > > If 'mode_psk' has been selected, then the 'psk_id' parameter MUST be > present. If 'mode_base' has been chosen, then the 'psk_id' parameter MUST > NOT be present. > > I suggest to use "header parameter" (2 instances), consistently with > above. Also, it would be good to define the parameter semantics already > here, instead of only much later in Section 7.2 when requesting for the > IANA registration. > > > [Section 3.1.1] > > * It says: > > > This mode applies if the COSE_Encrypt0 structure uses a COSE-HPKE > algorithm and has no recipient structure(s). > > I think you mean: > > > This mode relies on a COSE_Encrypt0 structure (see Section 5.2 of RFC > 9052) that uses a COSE-HPKE algorithm. Note that the COSE_Encrypt0 > structure has no recipient structure(s). > > * It says: > > > ..., this documents RECOMMENDS the use of the 'kid' parameter (or > other parameters) to ... > > "RECOMMENDS" is not a BCP14 word. Proposed rephrasing: > > > ..., it is RECOMMENDED to use the 'kid' parameter (or other > parameters) to ... > > * s/raw into the 'ek'/raw into the layer 'ek' > > (for consistency with the later "layer 'ek' parameter") > > (same comment for Section 3.1.2.2) > > > [Section 3.1.2] > > * It says: > > > This mode is selected if the COSE_recipient structure uses a COSE-HPKE > algorithm. > > I think you mean: > > > This mode relies on a COSE_Encrypt structure (see Section 5.1 of RFC > 9052), within which each COSE_recipient structure uses a COSE-HPKE > algorithm. > > * It says: > > > As stated above, the specification uses a CEK to encrypt the content > at layer 0. > > Maybe this sentence can be removed? > > > [Section 3.1.2.1] > > * It says: > > > It MUST be used for COSE-HPKE recipients ... > > I think you mean: > > > It MUST be used for encrypting COSE_recipient structures corresponding > to COSE-HPKE recipients ... > > * It says: > > > This value MUST match the alg parameter in the next lower COSE layer. > > In case the alg parameter is present in the next lower COSE layer at > all, right? (See the first paragraph in Section 3.1.2.2) > > * It says: > > > ... COSE_recipient CBOR-encoded deterministically with ... > > Proposed rephrasing: > > > ... COSE_recipient as deterministically CBOR-encoded with ... > > * It says: > > > Since it is not a header, it may be secret data that is not > transmitted. > > I think you mean: > > > Since it is not a header, it is not transmitted and thus it can safely > include data that may be secret. > > * It says: > > > It provides a means to convey many of the fields in COSE_KDF_Context. > > I think you mean: > > > It provides a means to convey many of the fields that are otherwise > conveyed within COSE_KDF_Context. > > > [Section 3.1.2.2] > > * There are 2 occurrences of: > > > raw key for the next layer down. > > In COSE-HPKE, isn't that "next layer down" specifically layer 0? > > * It says: > > > should be protected at layer 0 with external_aad. > > Should "should" be a normative SHOULD instead? > > It's better to clarify that the mentioned external_aad is the field in > the Enc_structure used to perform the encryption/decryption at the "next > layer down". > > > [Section 3.2] > > * It says: > > > ..., this means the value of "crv" parameter is suitable. > > I guess you mean: > > > ..., then the value of the "crv" parameter MUST be suitable too. > > > [Section 4] > > * s/'psk_id' parameter/'psk_id' header parameter > > > [Section 5.2.1] > > * It says: > > > TODO: recompute this for Recipient_structure > > Is that a remnant? > > * The caption of Figure 4 should be updated to reflect the use of > COSE_Sign1 as a wrapper. > > > [Section 6] > > * It says: > > > Additionally, with the two layer structure the CEK ... > > I think you mean: > > > Additionally, when using the two layer structure, the CEK ... > > > [Nits] > > * Section 3.1 > --- s/, which authenticates using/and authenticates using > > * Section 3.1.1 > --- s/contents/content (2 instances) > > * Section 3.1.1.1 > --- s/by RFC 9052/by [RFC9052] (as a hyperlink) > > * Section 3.1.2.1 > --- s/COSE encrypt/COSE_Encrypt > > * Section 3.1.2.2 > --- s/contents/content (2 instances) > --- s/strcture/structure > --- s/in the COSE_recipient/in the COSE_recipient structure > > * Section 3.2 > --- s/"kty" and "crv"/"kty", and "crv" > > * Section 4 > --- s/some extend/some extent > --- s/standardized it might/standardized, it might > --- s/with HPKE, the KDF/with HPKE. The KDF > --- s/consitute/constitute > > * Section 5 > --- s/that shows all/that show all > --- s/COSE_Encrypt and COSE_MAC/COSE_Encrypt, and COSE_MAC > > * Section 5.2 > --- s/In this example we assume/In this example, we assume > --- s/it will be/it would be > > * Section 5.2.1 > --- s/detatched/detached > > * Section 5.3 > --- s/key representation are/key representations are > > * Section 6 > --- s/assumes the sender/assumes that the sender > --- s/HPKE COSE/COSE-HPKE > --- s/generations/generation > --- s/ciphertext then/ciphertext, then > > > > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > > https://www.ri.se > ------------------------------ > *From:* Michael Jones <[email protected]> > *Sent:* Wednesday, June 4, 2025 10:28 PM > *To:* [email protected] <[email protected]> > *Subject:* [COSE] WGLC for draft-ietf-cose-hpke-13 > > > This note starts a two-week Working Group Last Call (WGLC) for the Use of > Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption > (COSE) specification > https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html. The WGLC > will run for two weeks, ending on Friday, June 20, 2025. > > > > Please review and send any comments or feedback to the COSE working group > at [email protected]. Even if your feedback is “this is ready for > publication”, please let us know. > > > > Note that this WGLC is intentionally running concurrently with a JOSE WGLC > for https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-08.html > because the drafts are closely related and their functionality is intended > to be aligned. Please reply to the JOSE WGLC on the [email protected] > mailing list. > > > > Thank you, > > -- Mike and Ivaylo, COSE > Chairs > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
