On Tue, Dec 02, 2025 at 03:57:43PM +0000, Michael Jones wrote: > Replying only to COSE, since Ilari's comments are about COSE. Replies are > inline below, prefixed by "Mike>". > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Monday, December 1, 2025 6:26 AM > To: [email protected]; [email protected] > Subject: [jose] Re: Design Team Decisions Applied to JOSE HPKE Specification > > While those decisions made sense for JOSE, I do not think those decisions > make sense for COSE: > > And as noted later, there are some security pitfalls here. > > * Integrate the new mode into the Message Encryption and > Message Decryption instructions from RFC 7516 and replace them. > > COSE does not have any analogous instructions. > > Mike> Yes, COSE does not have explicit Key Management Modes. That > said, the spec already clearly differentiates between Integrated > Encryption and Key Encryption modes, so I believe there's nothing > additional that needs to be done on this point.
COSE actually does have explicit Key Managment Modes / Content Key Distribution Methods. There are three: 'Direct Encryption', 'Direct Key Agrement' and 'Other' (a.k.a. non-direct). > * Utilize distinct algorithm identifiers for the use of HPKE for > Integrated Encryption and HPKE for Key Encryption. > > This would actually be dangerous. > > In COSE, any bulk encryption can be applied to CEK, so any bulk > encryption algorithm needs to be able to deal with CEKs properly. > > Mike> I maintain that since encryption of the plaintext and encryption > of the CEK are different operations with different outputs, they need > to be different algorithms in order to be fully-specified. There's > nothing dangerous about that - quite the opposite; it removes > ambiguity in the processing rules that could be a source of danger. COSE treats those two as the same operation. The danger here is that implementation can forget to check that the algorithm is used in the correct context. Whereas implicit context changes can not be forgotten (it will not interoperate at all). > Mike> Can you cite normative text saying that any bulk encryption > algorithm can also be applied to the CEK, Ilari? RFC 9052 Section 5.3 (AEAD algorithms) and Section 5.4 (AE algorithms) both recurse to non-direct recipients in Step 5 of encryption procedure and step 3 of decryption procedure. This allows for stuff like A128GCM keyed by A128GCM keyed by ECDH-ES (and lots of stuff that makes no sense). > * Only use the Recipient_structure when doing Key Encryption and > not when doing Integrated Encryption. > > COSE has per-level protected headers and application AADs, so aad structures > are required at every level. > > What could make sense is always using Recipient_structure, setting > next_layer_alg to NULL on layer 0. > > Hannes' PR https://github.com/cose-wg/draft-ietf-cose-hpke/pull/96 has > COSE HPKE secure the authenticated data in the normal COSE way. See > if you agree with that approach. AFAIU what that does, I see a problem: COSE unfortunately has unauthenticated bulk ciphers because the spec omitted the requirement that the bulk ciphers need to be authenticated. Those ciphers can be used in so-called "LAMPS attack" to attack the others. Of course, the proper way to deal with those algorithms is to not implement those at all. I do not know any sane way to use those for anything except attacks or vulnerabilities. For COSE-HPKE draft-18, the attack is prevented for HPKE recipients by the next_layer_alg field in Recipient_structure. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
