[Cryptography] upgrade mechanisms and policies

[Bill Frantz]

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. 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.

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.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032