> (BTW, I noticed that MLS > <https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-mls-ciphersuites>, > an > HPKE-centric message encryption, defines ciphersuites for HPKE. It is near > publication, so not just some early draft a fair number of people think > ciphersuites for HPKE are a good idea.. For example it defines > MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce > code and message size this is the way to go. There’s definitely few bytes > on the wire and you are only decoding one integer (plus the enc) That > saving is probably why most of the public key crypto in COSE is ID’d by > ciphersuite).
I think MLS and COSE-HPKE are completely different. COSE-HPKE is a generic common layer that does not assume a specific use case. I would prefer a design that keeps as much of HPKE's cipher suite agility as possible. -- Daisuke 2022年12月11日(日) 1:48 Laurence Lundblade <[email protected]>: > +1 for HPKE-v1-BASE > > Re title the draft "HPKE Base Mode for COSE” or similar because it’s not a > definition of all of HPKE for COSE > > Use a fixed array for the sender info that is tied to HPKE-v1-BASE. If > there becomes a need to change the array, then we’ll use.an algorithm > identifier different from HPKE-v1-BASE. For example, we could have a > different array for HPKE-v1-AUTH (if/when someone gets around to it and > there is actual need for it to be different). > > I’m pretty sure HPKE and COSE are well enough understood that we can fix > the array now. A fixed array is definitely less code than a map or a > variable array. For example with a map you have to do duplicate detection. > > LL > > > (BTW, I noticed that MLS > <https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-mls-ciphersuites>, > an > HPKE-centric message encryption, defines ciphersuites for HPKE. It is near > publication, so not just some early draft a fair number of people think > ciphersuites for HPKE are a good idea.. For example it defines > MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce > code and message size this is the way to go. There’s definitely few bytes > on the wire and you are only decoding one integer (plus the enc) That > saving is probably why most of the public key crypto in COSE is ID’d by > ciphersuite). > > > > On Dec 9, 2022, at 6:16 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Fri, Dec 09, 2022 at 11:17:32AM +0000, Hannes Tschofenig wrote: > > Hi all, > > I would like to get some clarity from the version discussion. > > At the beginning we discussed the following question: Do we need > something other than base mode for HPKE when used with COSE? > > > IMO, not currently. However, we should ensure, that such things can be > added in future without allocating new parameters. Which in turn impiles > that HSI (HPKE Sender Info) is either dictionary or polymorphic. > However, since each mode is its own special snowflake, I do not see need > for IANA registry. > > > Then, the discussions moved into how to encode future versions of HPKE > into the algorithm identifier. To me the discussion is a bit abstract > since there is (at least to my knowledge) to plan to work on a new > version of HPKE (given that the current version is not old). > > > Situation with future versions is even worse than with auth-MAC: With > auth-MAC, one at least knows what information needs to be encoded. But > with future versions, nobody even knows what is needed. > > So beyond ensuring HSI parameter is extensible, there is nothing that > can be done. > > > > So in summary: > > - Do just HPKE-v1 base mode for now. > - Possibly other stuff in future. > - Define HSI so that set of fields can change. > - Parametrized by alg. > - No need for registry. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
