Hi, I talked with Laurence during IETF 123, and I am the same on Laurence comment on COSE_MAC with COSE-HPKE in base mode should not be used.
Should discussion move to how to revise the draft? Changed to Auth mode? Delete the section? Or adding security consideration sentences to manually add pre-shared key? Akira ________________________________ From: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> Sent: Sunday, July 27, 2025 10:56 To: Laurence Lundblade <l...@island-resort.com> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; cose <cose@ietf.org> Subject: [COSE] Re: COSE_Mac with HPKE is very broken, right? You don't often get email from bcampbell=40pingidentity....@dmarc.ietf.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Agree with Laurence here. On Sun, Jul 20, 2025, 12:15 PM Laurence Lundblade <l...@island-resort.com<mailto:l...@island-resort.com>> wrote: 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 <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> 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" <l...@island-resort.com<mailto:l...@island-resort.com>> An: "Hannes Tschofenig" <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> CC: cose@ietf.org<mailto:cose@ietf.org> 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 <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> 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" <l...@island-resort.com<mailto:l...@island-resort.com>> An: cose <cose@ietf.org<mailto:cose@ietf.org>> Betreff: [COSE] COSE_Mac with HPKE is very broken, right? On Jun 21, 2025, at 11:07 AM, Ilari Liusvaara ilariliusva...@welho.com<mailto:ilariliusva...@welho.com> 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 -- cose@ietf.org<mailto:cose@ietf.org> To unsubscribe send an email to cose-le...@ietf.org<mailto:cose-le...@ietf.org> _______________________________________________ COSE mailing list -- cose@ietf.org<mailto:cose@ietf.org> To unsubscribe send an email to cose-le...@ietf.org<mailto:cose-le...@ietf.org> _______________________________________________ COSE mailing list -- cose@ietf.org<mailto:cose@ietf.org> To unsubscribe send an email to cose-le...@ietf.org<mailto:cose-le...@ietf.org> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. Aquest missatge i qualsevol arxiu adjunt a aquest correu electrònic són confidencials i estan destinats exclusivament per a la lectura i ús de l'individu o entitat a la qual van dirigits. L'accés a aquest missatge per altres persones no està autoritzat. Si vostè ha rebut aquest missatge per error, si us plau notifiqui al remitent immediatament i elimini aquest missatge del seu sistema. Està estrictament prohibit copiar, divulgar o distribuir aquest missatge o qualsevol part del mateix sense el consentiment exprés del remitent. Si el missatge està dirigit a clients o col·laboradors de OpenChip, el contingut del missatge s'entén subjecte als termes establerts en l'Acord de Confidencialitat subscrit entre les parts. This message and any attachments to this e-mail are confidential and are intended solely for the reading and use of the individual or entity to whom they are addressed. Access to this message by anyone else is not authorized. If you have received this message in error, please notify the sender immediately and delete this message from your system. It is strictly prohibited to copy, disclose or distribute this message or any part of it without the express consent of the sender. If the message is addressed to OpenChip's customers or partners, the content of the message is understood to be subject to the terms of the Non-Disclosure Agreement subscribed between the parties. Este mensaje y cualquier archivo adjunto a este correo electrónico son confidenciales y están destinados exclusivamente para la lectura y uso del individuo o entidad a la que van dirigidos. El acceso a este mensaje por otras personas no está autorizado. Si usted ha recibido este mensaje por error, por favor notifique al remitente inmediatamente y elimine este mensaje de su sistema. Está estrictamente prohibido copiar, divulgar o distribuir este mensaje o cualquier parte del mismo sin el consentimiento expreso del remitente. Si el mensaje está dirigido a clientes o colaboradores de OpenChip, el contenido del mensaje se entiende sujeto a los términos establecidos en el Acuerdo de Confidencialidad suscrito entre las partes.
_______________________________________________ COSE mailing list -- cose@ietf.org To unsubscribe send an email to cose-le...@ietf.org
