For the integration of HPKE into COSE I believe we have to take into account that COSE provides functionality for authentication using digital signatures and MACs. For this reason, the current WG draft says: (a) Use base mode for HPKE and (b) use the existing COSE signature/MAC mechanisms.
Is there a problem with this approach? Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Laurence Lundblade Sent: Wednesday, November 23, 2022 10:25 PM To: Ilari Liusvaara <[email protected]> Cc: cose <[email protected]> Subject: [COSE] COSE_Mac + COSE_Recipient + HPKE (was Re: The main two COSE-HKPE modes) Seems like we ought to get to the bottom of this as part of making sure we do the whole COSE HPKE thing well. In particular, if this is not recommended, then maybe it should say so in security considerations. > On Nov 22, 2022, at 11:19 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Tue, Nov 22, 2022 at 09:25:08AM -0800, Laurence Lundblade wrote: >> >>> On Nov 22, 2022, at 12:58 AM, Hannes Tschofenig <[email protected]> >>> wrote: >>> >>> FWIW both modes are already described in draft-ietf-cose-hpke. >>> >>> COSE_Mac/COSE_Mac0 and COSE_Sign1/COSE_Sign are wrappers covering >> the entire COSE_Encrypt/COSE_Encrypt0 payload. >> >> It’s not COSE message wrapping/nesting here. RFC 9052 section 6.1 >> allows the use of a COSE_Recpient (e.g., with HPKE) to establish the >> secret key used with HMAC for COSE_Mac as kind of an alternate way of >> signing data. I’m not sure what the use case is and why it’s better >> or worse than ECDSA, Edwards and other such signing, but the COSE >> authors went to a lot of trouble to create it and provide a lot of >> examples for it. >> >> It seems not a lot (close to zero) work to support it with two-layer >> HPKE, so we should. > > I do not think that actually works, due to two problems: > > - HPKE operates in base mode, which has no sender authentication. Yes, this seems right. RFC 9052 section 6 says to use it with ECDH SS (but doesn’t say it’s bad to use with with ES; maybe it should). Personally, I think we should probably support mode_auth for HPKE. That, or be prepared for it. > - There is implicit key wrap, so in terms of security considerations > for COSE, "no proof of origin is implied". I think what you're saying is that the MAC key is randomly generated outside of HPKE and then wrapped by HPKE. The wrap is authenticated because it’s AEAD though, so I’m not sure what the problem is. The key for the MAC will have originated outside of HPKE, but the environment outside of HPKE has to be trusted. > > Furthermore, even in HPKE auth mode with export-only (no implicit key > wrap) if the private key is shared among multiple entities, those > entities can forge messages to each other (analogous issue is covered > in COSE security considerations for ECDH). HPKE is no different in this regard than COSE_Mac with ECDH-SS, right? Maybe that is OK for some use cases. RFC 9052 warned, but allowed it. One particular case I know of is signing with two algorithms (e.g., one PQ one not) and hashing the bulk content (e.g., large firmware) only once. You can’t do that with COSE_Sign because of the way the TBS bytes are computed. LL _______________________________________________ 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
