Re: [saag] A case against algorithm agility (long)

[ianG <[e-mail]>]

On 5/05/2014 03:30 am, Andrey Jivsov wrote:
> On 05/03/2014 11:45 AM, ianG wrote:
>> I've jotted down some notes on the case against agility, as mooted.
>> Sorry, long.
>>
>> It should be called "algorithm agility considered harmful" but I've
>> found that some people are irrationally offended by words.  Offense
>> doesn't worry me, but distraction helps nobody.
>>
> ...
> 
> It is a good idea to limit the number of possible permutations of
> allowed algorithms.


:)

> However, the pros for the algorithm agility are:
> * compliance with standards (unless all standards in the world specify
> the same suite)


Why is this a pro?  What conceivable benefit is there to users in
adopting others' standards, when they already have their own?

We're talking about a single protocol that communicates with its own
agents only;  it's TLS versus SSH, they don't ever talk to each other,
it's not like Esperanto versus German.

Here you are in a standards setting, which means you set standards.  By
outsourcing the setting of standards, that means you are not doing the
job.  I can see the argument that you simply want to use other peoples'
work, but I can't see why you would want to save on work by re-use, and
duplicate with your own as well.  Makes no sense to me.


> * upgrade to new algorithms


Yes, just to set the context, there are three different mechanisms
available.  Algorithm agility is (to me) the substitution of new
algorithms within a protocol connection context.  There is also suite
substitution which sets the whole stack.  Then there is also version
upgrade which changes the whole protocol.  Latter is TLS1.1 => TLS1.2.

> (the time-line of the "old" and the "new"
> algorithms typically overlap)

(a result, not an objective)

> * easier system maintenance (it's easier to add only a new algorithm to
> an old product that is only maintained as opposed to actively developed)


Only if you ignore all the other things going on.


> * there might be no single algorithm that is perfect for everybody


The combination of your points 1 & 4 means that every algorithm that has
any single benefit has to be supported by everyone, taken to the extreme.

Again, you have to look hard and deep:  why are you opening the door to
supporting more than one?  Why are you opening the door to many many
algorithms?  Where's the benefit for the user?




iang