I can see how Daisuke and/or others think this is a nice addition to COSE-HPKE because it is there Section C.5.2 of RFC 9052. I thought it was nice until Ilari commented and I thought about it.
However, very literally, no one should ever use COSE_MAC with COSE-HPKE in base mode. It provides no protection. It is open to attack. It seems a large disservice to publish examples that misdirect people into thinking this is something to consider. What if they don’t think it through like we all didn’t think it through (except Ilari)? I have a strong opinion that it should be removed. LL > On Jul 20, 2025, at 11:20 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Laurence, > > the examples in the appendix are just illustrations. You can use the same > technique with all ECDH variants from the body of the draft. > > On a higher level, this functionality was added on request by Daisuke, who > noticed that this features are available with the main COSE specification but > not with the COSE HPKE draft. That is why we added it. If we, for some > reason, decide that we do not need this feature for COSE HPKE or for COSE in > general then we should remove it. > > Ciao > Hannes > > Gesendet: Freitag, 18. Juli 2025 um 18:09 > Von: "Laurence Lundblade" <[email protected]> > An: "Hannes Tschofenig" <[email protected]> > CC: [email protected] > Betreff: [COSE] Re: COSE_Mac with HPKE is very broken, right? > 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]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
