It’s kind of the same question as to why COSE_Encrypt is distinct from COSE_Sign or why there is HPKE mode_base that is separate from HPKE mode_auth and perhaps why integrated signing and encryption <https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme> like ECIES <https://www.secg.org/sec1-v2.pdf> and HPKE mode_auth aren’t more popular (seems like they have some very good characteristics to me).
Probably the main answer is that the payload is authenticity-protected in some other way — TLS, IPSec or something proprietary. End-end system architectures vary quite a lot and often have legacy components. A good example of no authenticity at all is for-pay content distribution like streaming TV shows, sports events and such. Another may be use of an unreliable transport (e.g., UDP) and being OK with drop outs (e.g., voice or video). It’s not possible to authenticate the stream because of the drop outs and it’s too expensive to authenticate individual packets. Another might be difficulty with end-end key management for authenticity. There are probably other examples, but I admit they are difficult to come up with. Authenticity should be strongly recommended. LL > On Mar 4, 2023, at 9:57 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi Laurence, > > > thanks for the feedback. > > Could you say a bit more about the use case you have in mind where > authenticity is not required? > > > Ciao > Hannes > > > Am 03.03.2023 um 21:22 schrieb Laurence Lundblade: >> The COSE HPKE draft has this security consideration: >> >> The COSE_Encrypt structure MUST be authenticated using COSE >> constructs like COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0. >> >> It is really good this text is there, but I’d like to tweak it a bit: >> >> * Change MUST to SHOULD because there are (theoretically) cases >> where authenticity is not needed. Perhaps some comment that most >> use cases will need authenticity to defend against forgery attacks >> — the attacker is likely to have access to the recipients public >> key. (Also prefer to avoid 2119 terms belong in security >> considerations). >> * Say that the AEAD in HPKE base_mode is not a substitute for the >> authenticity provided by COSE_Sign and such. >> >> >> LL >> >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
