[Cryptography] upgrade mechanisms and policies

[Christian Huitema]

On Saturday, April 11, 2015, at 11:50 AM, Bill Frantz wrote:
> To: Michael Kjörling
> Cc: cryptography at metzdowd.com
> 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?

There are two main reasons for creating a new protocol version: bug fixes, or performance enhancements. 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. We may debate whether the fraction is 10%, 20%, or 30%. It depends on quality controls during the making of the new version. But we can certainly not assume that the fraction is 0%. Performance enhancements have a similar track record. They may very well introduce a regression of some kind. So, yes, definitely, it can happen that sometimes after TLS/1.5 is published, we discover an issue, and realize it is actually less secure than 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.

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.

-- Christian Huitema