[Ach] meta-question on algorithm agility

[ianG]

On 5/05/2014 10:32 am, Hanno Böck wrote:
> On Fri, 02 May 2014 23:20:11 +0100
> ianG <iang at iang.org> wrote:
> 
>> Imagine that algorithm agility was banned.  No more choice!  How much
>> resource would this free up?
> 
> I get your point why you don't like algorithm agility, but I really
> don't know what the alternative would be (or if it wouldn't be much
> worse).

There are three mechanisms available that I know of:

  1) algorithmic agility being the ability to negotiate say TDES for AES.

  2) suite agility, being the ability to negotiate
RSA1024/TDES/CBC/SHA1-HMAC for RSA4096/AES256/CTR/HMAC-SHA256.  That is,
you pick suite 1 and that's it, that's what you get, no more discussion.

  3) version negotiation.  This is picking TLS1.0 versions TLS1.2.  You
get the entire protocol.


> We probably agree that from time to time, there are improvements we'd
> like to see in encryption.
> E.g. a few years ago forward secrecy was "some exotic stuff", TLS
> implementations rarely supported it, today everyone's running around and
> saying "we need forward secrecy" (and - for very good reasons).
> 
> If I should make a prediction, I think in a few years from now we'll
> have a strong trend towards "we need 100% timesafe and branch-free
> algorithm implementations to avoid sidechannels" and maybe at some
> point people may also wonder if AES is still secure enough [1].
> 
> 
> Now I wonder: How would such a transition work without algorithm
> agility?


Yes on the whole, if we were at TLS1.5 at the moment, what we would do
is design a new ciphersuite for TLS1.6.  Then, when that's good and
ready, and the protocol updates are good and ready, we announce a freeze
on protocol & suite changes in TLS1.6 and start to thrash it through the
testing and demo and bleeding edge distros.  At some point we announce
it to RELEASE and start the process of pushing everyone on to it.  At
the same time we move TLS1.4 to DEPRECATE and start issuing grizzly
warnings & FUD in the MSM.

It's just like software distro.  We know how to do this.


> I'm aware that algorithm agility doesn't work extremely well
> for the transition, but it works at least somewhat. We can e.g. probably
> at some point in the near future deprecate most of RC4 and SSL3 use.


Right.  We deprecate SSL3 and we never mention RC4.  It falls out in the
wash.


> We do that by deploying new algorithm choices and use them when
> available and when pretty much everyone has switched to systems that
> don't need "ugly old algorithm" any more we can deprecate then.
> How would such a transition work in a one-algorithm-scenario?
> 
> [1] http://2012.sharcs.org/slides/biryukov.pdf




iang