[Cryptography] a question on consensus over algorithmic agility

[Peter Fairbrother]

On 26/06/14 22:21, John Kelsey wrote:
> There are a couple point I think are really important to think about
> if you're trying to get algorithm agility in a protocol:
>
> a.  The security benefit of algorithm agility is entirely in being
> able to *stop* using some algorithms while still functioning.
>
> This means that you only really get this benefit if you have at least
> two ciphersuites that are both SHALLs.  If everyone implements RC4 +
> CRC32 (the SHALL), and some people also implement AEC-GCM (the
> SHOULD), then when someone finally realizes that RC4+CRC32 is
> insecure, you can't actually get rid of it.  Indeed, version rollback
> attacks will work even on implementations that support AES-GCM,
> because they have to be able to interoperate with implementations
> that don't.
>
> b.  A lot of the time, the "algorithm" that gets broken isn't a
> cryptographic primitive like AES, but rather some surrounding
> chaining mode or padding scheme or something.
>
> This means that if there are two ciphersuites, they should be pretty
> different to minimize the overlap between them.  For example, you
> might do AES-GCM and 3DES-CBC+HMAC-SHA256.  The same idea applies to
> more ciphersuites.
>
> c.  It's critical to make sure there's a simple way for a particular
> implementation to stop using a given algorithm, and that this is
> built into the protocol.  The ciphersuite negotiation probably needs
> to be really simple.

I was almost convinced, for a moment. Two or maybe three suites, only 
SHALLs allowed, so there is no question of whether a suite is installed 
or fit for purpose - sounds good.

But who decides when to stop using an algorithm suite?  The luser 
client? The boss server?

It's certainly not the cryptologist.


-- Peter Fairbrother