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

[Christopher Allen <[e-mail]>]

On Tue, Mar 7, 2023 at 12:25 AM Christopher Allen <
[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/

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