[Cryptography] upgrade mechanisms and policies

[ianG]

On 11/04/2015 07:28 am, Bill Frantz wrote:
> On 4/10/15 at 11:50 AM, iang at iang.org (ianG) wrote:
>
>>> As a corollary:  We can avoid "flag day" problems by
>>> introducing the new thing on cycle N, then deprecating
>>> the old thing on cycle N+2 and outlawing it on cycle
>>> N+4.  This sort of well-planned transition works a lot
>>> better in non-emergency situations.
>>
>>
>> The "odds & evens" version replacement approach is what I think we'll
>> drift to in the future, for those protocols have decided to dispense
>> with the internal upgrade possibility.
>
> I don't think it makes much difference if you have a protocol which
> allows negotiation of algorithms from within the protocol, think TLS, or
> one that has only one protocol, but lets you negotiate which version of
> the protocol you use, like the E protocol.


Negotiating the protocol version as N or N+1 means that in N+1 we can 
fix all the *protocol* bugs found in N.  Algorithmic agility doesn't 
cover that territory, although once, with the switch to RC4, it was sort 
of kludged in by going backwards to a deprecated algorithm.

Count up how many protocol bugs we have seen in TLS.  Versus how many 
algorithm failures we've experienced.

The ratio is about 10:1 - the real problem is in protocols, not in 
algorithms.  When WGs look at the algorithms, they are looking at the 
wrong area; worrying about algorithms and trying to preserve agility in 
algorithms means they're distracted by the sex appeal of beautiful 
cryptography rather than the ugliness of protocols.


> The only issue with only one
> crypto suite per version is that you can't assume that version n+1 is
> better than version n.


I don't understand how that follows, but my suspicion is that it is 
based on false assumptions about algorithms being more important than 
protocol?


> The former kind of protocol rather reminds me of my great grandfather's
> axe. It's the same axe, it's just had 7 new handles and 3 new heads.


Yep, that's a good analogy.  We could call it the grandfather's axe 
approach :)



iang