Inline On Wed, Mar 8, 2023 at 11:50 AM Laurence Lundblade <[email protected]> wrote:
> 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 agree with this comment about COSE HPKE, I was initially really confused by this, and it took patient feedback from the list before I could make sense of the design approach, and arguments from the authors. A few factors that made it harder for me to understand: 1. How should COSE HPKE be similar or different from JOSE ECDH-ES? 2. How should COSE HPKE keys be similar or different from JOSE ECDH-ES JWKs? 3. When is explicit parameterization preferred over adding many registry entries for cipher suites? > > 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. > > I agree with this comment, I think COSE HPKE might tend to be more aggressively profiled / restricted due to the choice of parameterization and agility, but that is not necessarily a bad thing, it is just drawing the lines slightly differently than JOSE and JOSE profiles have in the past. > 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]> 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/ > > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
