[Cryptography] upgrade mechanisms and policies

[Bill Frantz]

On 4/11/15 at 1:04 PM, huitema at huitema.net (Christian Huitema) wrote:

>We do have lots of experience with bug fixes, and part of that 
>experience is that a substantial fraction of bug fixes 
>introduce another bug.

Indeed. There was a paper published in the 1060s or 1970s which 
argued that as systems aged, the number of bugs introduced per 
bug fixed became larger. It also contend that for OS/360, the 
number of bugs introduced with each bug fix had grown to be 
larger than 1.

>Assuming that the occurrence of regressions is low enough, 
>there is always a simple fix. Instead of changing the 
>negotiation mechanism to, for example, "prefer 1.4 to 1.5," it 
>should be possible to simply "reissue 1.4 as 1.6." A bit of a 
>waste in terms of numbers, but very little engineering cost.

However, this leaves the policy decision with the standards 
group which assigns the numbers. IMHO, the policy decisions 
should be more diverse and made by people who understand the 
security requirements of the application. For example, some 
applications may place a higher priority on authentication than 
on secrecy, while others would make that tradeoff the other way. 
People closer to the application than the standards group should 
set the policy of which version to trust.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Re: Hardware Management Modes: | Periwinkle
(408)356-8506      | If there's a mode, there's a   | 16345 
Englewood Ave
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032