Hi Christopher, I’m redirecting this to the COSE work group. There are other groups like the CRFG <https://irtf.org/cfrg> that might be even better. The CBOR work group is not the right place for it.
I have a few comments: COSE is not an end-end system with guaranteed interoperability. It has to be profiled to interoperate. It is designed to serve a huge range of use cases so it has a lot of options. COSE mostly does take a cipher suite approach as much as it can. The main author is no longer with us to discuss this, but I suspect it is for some of the reasons you give. I mostly like cipher suites myself. In recent work here, COSE HPKE <https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/> is however going for the full agility that you criticize. I don’t think dCBOR has anything to do with crypto agility so I’m not sure why you mention it. I primarily work on EAT <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat> a derivative of CWT/JWT. EAT is also intended for lots of use cases and to be profiled. Your comments here are making be consider adding text that recommends that EAT profiles allow only very a limited numbers of algorithms. LL > On Mar 7, 2023, at 6:53 PM, Christopher Allen > <[email protected]> wrote: > > On Tue, Mar 7, 2023 at 12:25 AM Christopher Allen > <[email protected] > <mailto:[email protected]>> wrote: > When looking at switching back to SHA-256 from BLAKE3, we decided to forebear > crypto-agility with Gordian Envelope, especially as we have only 1 > cryptographic algorithm (the hash), and desire to the conservative stance > that having only one makes it easier to review, and if something major > happens, we'll revise the standard to v2. > > This is the approach that more and more cryptographers and protocol designers > like Wireguard are taking. I'm working now on an article about the various > risks of crypto-agility, and alternatives like crypto-suites, methods, better > layering, etc. > > I’ve finished the article I was working on talking about why we’re > restricting the use of cryptographic agility in Gordian Envelope: > > https://www.blockchaincommons.com/musings/musings-agility/ > <https://www.blockchaincommons.com/musings/musings-agility/> > > Basically, I believe there are flaws with a full-throated embrace of > cryptographic agility, mainly: > > * High Costs > * Bad Interactions > * Downgrade Attacks > > Though there are obvious advantages to being able to nimbly switch to a new > algorithm if a problem emerges with an old one, I think that switchover > ability should be highly limited. For Gordian Envelope, I plan to include > just two options for the hash algorithm we use: a current version and a > reserved tag to switch to if/when problems arise. > > There are other alternatives that I talk about in the article, such as cipher > suites, expiration dates, methods, and good usage of layering, but my general > philosophy after 23 years of experience since the release of IETF TLS 1.0, is > the less, the better. > > The article goes into all of this in more depth. > > -- Christopher Allen > _______________________________________________ > CBOR mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
