Re: [COSE] [Cbor] Gordian Envelope and Crypto-Agility for its Hash

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Tue, Mar 7, 2023 at 12:25 AM Christopher Allen <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor