> On Nov 24, 2022, at 1:14 AM, Hannes Tschofenig <[email protected]> > wrote: > > 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?
Seems like an incomplete integration of HPKE with COSE. Here’s a few reasons I can think of for supporting mode_auth. These are all for encryption + authentication. - Less bytes on the wire because you don’t need a COSE_Sign (probably only 10-30 less but something) - Less CPU because of one-pass processing of the bulk payload (Just the AEAD, not an AEAD and a hash) (May not work out as an advantage for firmware because of issues related to counter mode). - Simpler implementation and less code and maybe a lot less memory because you might avoid a big intermediate payload buffer between the encryption and the hash and you don’t have to decode COSE_Sign - Lines up better for the HPKE crowd that really want to do HPKE for as much as possible - May line up better for algorithm and key selection for some use cases (and not for others, but we’re not taking away COSE_Sign) This could be in a separate draft, but we should at least anticipate how mode_auth is distinguished from mode_base now. LL > > 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
