[Cryptography] upgrade mechanisms and policies

[Bill Frantz]

On 4/11/15 at 4:52 AM, michael at kjorling.se (Michael Kjörling) wrote:

>On 10 Apr 2015 23:28 -0700, from frantz at pwpconsult.com (Bill Frantz):
>>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.
>
>On what basis however can we assume that a hypothetical future TLS 1.5
>will be "better" (either in some objectively measurable sense, or in
>every sense) than a likewise TLS 1.4?

All of the protocols I know of that have version negotiation 
design the protocol to try to agree on the highest numbered 
version. What I think we need is to have each end have a 
preference order for versions numbers and pick the offered 
version which is highest in the preference list.

With this kind of mechanism, each version could have only one 
algorithm for each function, eliminating algorithm negotiation, 
and a lot of complexity from implementations. The preference 
ordered list is the place for each end to specify policy, as 
John Denker suggests. Note that if an endpoint considers a 
version to be spyware, it can leave it out of the list entirely, 
causing the connection attempt to fail unless another version 
can be agreed on. As Michael Kjörling points out:

>Newer does not necessarily mean better,
>especially in the security field, and in fact something that has stood
>the test of time may actually be _better_ than something entirely
>newfangled.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032