As promised, a summary of my points from yesterday's session. All of these are *very* weakly held points, and are minor, not addressing any actual security problems, but ensuring some additional robustness of the approach.
1. Domain separator in the info field. (See also my message above in the thread). Adding domain separation is always nice. The info field here does not have to be finalized, but can still be passed down to the caller, just prefixed with a COSE HPKE dependent prefix. This makes cross protocol attacks less likely, but they are already not particularly likely in HPKE use cases, hence are a minor issue. Concretely, I would set the info argument of HPKE to something like "HPKECOSE" || <info>, where || is concat, and <info> is the info argument supplied by the caller. 2. For the discussion of associated data vs. info field. In the case of HPKE without sender authentication, those two fields provide the same function, they bind some additional information to the ciphertext, and decryption will fail if the additional information supplied when decrypting differs from the information used when encrypting. There are two, very theoretical points that make me prefer the info field over the associated data, but as mentioned, I do not have a strongly held opinion here either. The first point is that technically, the associated data of an AEAD is not guaranteed to be confidential, while the inputs into a KDF are usually expected to be. This is a highly theoretical objection, though, since in practice, every single actually used AEAD does not leak the associated data, the definition just does not force this behavior. The second reason is a bit more practically relevant, but also does not really apply to HPKE: while using different associated data does have the same function as different info fields, two encryptions with different associated data under the same key still count against the key exhaustion limits, while two different info parameters do not (assuming no collisions on the hash function). This can be very relevant for keys that might run afoul of key exhaustion limits, but HPKE keys are usually used exactly once, so are at no risk of exhaustion. Both points combined lead to my stylistic preference of info over associated data, but as mentioned now for a third time, going with associated data is a completely fine and defensible choice as well. On Tue, Jun 24, 2025 at 3:06 PM Hannes Tschofenig <Hannes.Tschofenig= [email protected]> wrote: > Hi Thomas, > > thanks for the feedback. I have created a PR to address it: > https://github.com/cose-wg/HPKE/pull/83 > > Ciao > Hannes > > *Gesendet: *Dienstag, 17. Juni 2025 um 13:32 > *Von: *"Thomas Fossati" <[email protected]> > *An: *"Michael Jones" <[email protected]> > *CC: *"[email protected]" <[email protected]> > *Betreff: *[COSE] Re: WGLC for draft-ietf-cose-hpke-13 > On Wed, Jun 04, 2025 at 08:28:52PM +0100, Michael Jones wrote: > > 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]<mailto:[email protected]>. Even if your feedback > > is "this is ready for publication", please let us know. > > I hadn't read this draft before. At first glance, the mechanics look > fine, but I may be missing some important details. > > Here are a few editorial comments from a quick scan of the document. > > ---- > s/this documents/this document/ > s/public key the sender/public key that the sender/ > s/recipient protected/recipient-protected/ > s/the whole COSE encrypt/the whole COSE_Encrypt0/ (or COSE_Encrypt???) > s/public key the sender/public key that the sender/ > > I was unable to parse: "It also mitigates attacks where a > person-in-the-middle changes the following layer algorithm from an AEAD > algorithm to one that is not foiling the protection of the following > layer headers)". Could this be simplified? > > Grammar: > > OLD > When encrypting the content at layer 0 then the instructions in Section > 5.3 of [RFC9052] MUST to be followed, which includes the calculation of > the authenticated data strcture. > NEW > When encrypting the content at layer 0, the instructions in Section 5.3 > of [RFC9052] MUST be followed, including the calculation of the > authenticated data structure. > > Straighten a backwards sentence: > > OLD > For the algorithms defined in this document, the valid combinations of > the KEM, "kty" and "crv" are shown in Figure 1. > NEW > The valid combinations of KEM, "kty" and "crv" for the algorithms > defined in this document are shown in Figure 1. > > s/to some extend/to some extent/ > s/maintain the tradeoff between/strike a balance between/ > s/consitute/constitute/ > s/examples that shows/examples that show/ > > some mildly invalid EDN: > * Figure 2: extra commas > * Figure 3: extra commas > > s/COSE_MAC/COSE_Mac/ > s/COSE_MAC0/COSE_Mac0/ > s/random number generations/random number generation/ > > De-clunkify paragraph: > > OLD > HPKE assumes the sender is in possession of the public key of the > recipient and HPKE COSE makes the same assumptions. Hence, some form of > public key distribution mechanism is assumed to exist but outside the > scope of this document. > NEW > Both HPKE and HPKE COSE assume that the sender possesses the recipient's > public key. Therefore, some form of public key distribution mechanism is > assumed to exist, but this is outside the scope of this document. > > The IANA registration requests appear as an inextricable cluster . > I suggest adding an NL to separate the blocks logically. > ----- > > cheers, t > > > 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]<mailto:[email protected]> mailing list. > > > > Thank you, > > -- Mike and Ivaylo, COSE Chairs > > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > 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]
