Each library will have a small window (probably no more than 3 versions at any time) of acceptable protocol versions.
A new version will be specified, with a brand new KDF salt, every time we need to improve the protocol to address a security risk. Additionally, we will upgrade the protocol version at least once a year, even if no security risks have been found in the latest version of the protocol.
I was reading through this initially with a lot of skepticism because I imagined an xkcd Standards parallel where the author was (falsely) convinced of having arrived at a novel solution. (To their credit they end with a note that the idea isn’t novel.) Anyway, these two paragraphs have about convinced me of it’s viability. Of course it still hinges on consensus, but it builds in a mechanism that resists inertia at the protocol level.
The key ingredient here to me is making the process mundane, expected. Much like short lived TLS certificates — as popularised by Let’s Encrypt — have moved the vast majority of web facing certificate issuances into the realm of Fully Automated Luxury Cryptography, I think such a policy has the potential to truly scale and keep a distributed protocol nimble. It’s only a shame that ‘agility’ has already been burned because it’s the ideal name for it.
