Hi Hannes, A short reply — Section C.5.2 of RFC 9052 uses ECDH-SS. With “SS” the derived key material is suitable for authentication of the content. With HPKE base mode, the derived key material is not. So, I still think the same.
LL > On Jul 18, 2025, at 3:01 PM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Laurence, > > let me try to clarify what HPKE in Base Mode does when used with COSE in a > key encryption context. > > If the sender has access to the recipient's public key, they can use it to > encrypt a randomly generated Content Encryption Key (CEK). This CEK is then > used to encrypt the actual plaintext. In this model, anyone can send an > encrypted payload to the recipient. There is no authentication of the sender > inherent in HPKE Base Mode - by design. However, authentication of the sender > can be provided separately at the COSE layer, as noted in the Security > Considerations section. > > In short, HPKE functions as a key establishment mechanism for COSE's > encryption process. > > Now, let us apply the same logic to message authentication: > > If the sender has the recipient's public key, they can use it to derive a > shared secret, which is then used to compute a MAC over some data. The same > caveats regarding sender authentication apply here: HPKE Base Mode provides > no sender identity assurances. > > This approach aligns with how COSE treats key establishment. It's > conceptually the same as the example in Section C.5.2 of RFC 9052 > <https://datatracker.ietf.org/doc/html/rfc9052#name-examples-of-maced-messages>, > where ECDH is used to derive a symmetric key for HMAC-SHA-256. > > So, there is nothing incorrect and nothing particularly novel. This > functionality is also in the original COSE specification. > > To summarize: > > If sender authentication is required, it must be explicitly provided via a > corresponding COSE structure. > > If confidentiality is needed, COSE_Mac is not the right choice. Use an > encryption-based structure instead. > > We have already included relevant text in the Security Considerations > section. If you believe it could be improved, feel free to suggest > alternative wording. > > Ciao > Hannes > > > > > Gesendet: Freitag, 11. Juli 2025 um 21:54 > Von: "Laurence Lundblade" <[email protected]> > An: cose <[email protected]> > Betreff: [COSE] COSE_Mac with HPKE is very broken, right? > On Jun 21, 2025, at 11:07 AM, Ilari Liusvaara [email protected] wrote: > > > > The COSE_MAC stuff seems very broken, at least in base mode. What is > > to prevent an attacker that has victim public key from choosing the > > message, MACing it with random key, and then encrypting the key to > > recipient? > > > > That would not work in auth mode, but it is not supported (and it > > would still be a lot weaker than proper signatures). > > I filed an issue [cose-mac-github] to be sure we thought about this. I’ve > thought about it and agree with Ilari. [cose-hpke-mac] is a really bad > example. No one should ever use because it is insecure. > > Two options for the document: > > 1) Remove the example entirely > > 2) Leave the example, and explicitly warn in the example text that it is > entirely insecure and is only there for the sake of completeness to show what > can be done with COSE-HPKE. I think this is so insecure that it needs an up > front warning, not just a few words in the security considerations section. > > Why is this so bad — it would seem to provide integrity protection and maybe > authentication but provides neither. COSE-HPKE is used to encrypt a key being > sent to the recipient. That key is used for integrity protection and maybe > authentication. The problem is that the sender can choose the key so they can > pick any key and MAC any message. No security services are provided to the > recipient. > > The problem here is that HPKE is used in base mode. It is only providing > encryption. As Ilari says, this construct would be OK if HPKE was used in > auth mode, but the draft doesn’t support auth mode. > > I prefer option 1). When we make the cose-hpke-auth standard, we can put the > example in. > > LL > > > [cose-hpke-mac]: > https://www.ietf.org/archive/id/draft-ietf-cose-hpke-15.html#name-cose_mac > [cose-mac-github]: https://github.com/cose-wg/HPKE/issues/81 > > _______________________________________________ > 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]
