On Wed, May 31, 2023 at 05:44:02PM -0500, Orie Steele wrote: > > On Wed, May 31, 2023 at 2:02 PM Hannes Tschofenig <[email protected]> > wrote: > > > Hi Orie, > > > > Thanks for your contribution. I am trying to understand your suggestion > > better. > > > > When it comes to the algorithm registry there are only two choices: > > > > - A la carte, or > > - Ciphersuites > > > > From your text below I believe you are arguing for a ciphersuite as Apple > > uses it. > > > > For the initial versions of the COSE-HPKE we used the ciphersuite approach > > and then we switched to the a la carte approach. > > > > Is it correct that you want to move back to the ciphersuite approach? > > > > Yes, I think "alg" should work the way it has previously worked, for > both keys and envelopes. > > I don't think a new "alg" system should be invented in COSE-HPKE.
It does work like it worked before. Restricting bulk encryption using "alg" has never worked. > > Once this decision has been taken, there is the question about where to > > take the registered algorithm values from. > > > > I suggest requesting registrations only for the algorithm suites that > people want to use in COSE-HPKE, here: > > https://www.iana.org/assignments/cose/cose.xhtml 14 as of HPKE 2023-05-18, vulnerable to combinatorial blowup. > This follows the conventions we have for ECDH alg's, which is what > many people will be familiar with, and will potentially be upgrading > from when considering COSE-HPKE. > > This will also result in simpler keys and envelopes. ECDH algs do not work that way. Which is why there are only 2 fundamental ECDH-ES algorithms, plus 3 size optimizations. And as of currently, it is able to match all the pre-quantum stuff. > > Version -05 of the draft takes the values directly from the IANA > > HPKE registry. In an attempt to avoid creating conflicts with the > > COSE algorithm registry, they had to be used in the newly designed > > structure rather than in the “usual” COSE algorithm parameter. > > Yes, I disagree with this design choice. As note, there is need to define new stuff because of the ciphertext- is-not-key problem. > It is more contentious and requires more work, because it has to > define this "new way of handling alg with an external registry". I don't think it will be more work up-front. And it will definitely not be more work in the long run. Up-front, it is encoding three integers explicitly versus defining how to extract those from alg values. Long-run, it is doing nothing versus registering all the easily dozens of new alg values standing for various triples (and hoping nobody gets any "smart" ideas). > This complexity is not coming from HPKE, it is coming from wanting > to establish new conventions in COSE Keys and Envelopes that avoid > registry updates related to new algorithms. The complexity is coming from HPKE. And what I think is the simplest way to handle it avoids registry updates. > If it is going to be attempted, it would be better done in a > separate document, as an update to COSE. Attempted? I consider "attempted" to mean it might not work. This stuff is proven to work. And I do not see any need to update COSE. > However, I would still object because as Chris said, it seems to go > against the previous conventions, and current trends in security best > practices. It does not go against the previous conventions. And many "best practices" are actually just fads. Only some will truly stand the test. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
