<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 April 2015 at 19:50, Bill Frantz <span dir="ltr"><<a href="mailto:frantz@pwpconsult.com" target="_blank">frantz@pwpconsult.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/11/15 at 4:52 AM, <a href="mailto:michael@kjorling.se" target="_blank">michael@kjorling.se</a> (Michael Kjörling) wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10 Apr 2015 23:28 -0700, from <a href="mailto:frantz@pwpconsult.com" target="_blank">frantz@pwpconsult.com</a> (Bill Frantz):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only issue with only one crypto suite per version is that you<br>
can't assume that version n+1 is better than version n.<br>
</blockquote>
<br>
On what basis however can we assume that a hypothetical future TLS 1.5<br>
will be "better" (either in some objectively measurable sense, or in<br>
every sense) than a likewise TLS 1.4?<br>
</blockquote>
<br></span>
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.<br>
<br>
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: </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Newer does not necessarily mean better,<br>
especially in the security field, and in fact something that has stood<br>
the test of time may actually be _better_ than something entirely<br>
newfangled.<br></blockquote></span></blockquote><div><br></div><div>Wat? This is crazy talk.</div><div><br></div><div>Clearly the only sane policy is to believe that the latest version of X is the most secure. And if you know about X you ought to also know about the problems with X-1, X-2,.... So, sure, each end indicates which versions it is prepared to use, but of the intersection, _surely_ highest wins?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
<br></span>
Cheers - Bill<br>
<br>
------------------------------<u></u>------------------------------<u></u>-----------<br>
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle<br>
<a href="tel:%28408%29356-8506" value="+14083568506" target="_blank">(408)356-8506</a>      | 10 programmers get it wrong. | 16345 Englewood Ave<br>
<a href="http://www.pwpconsult.com" target="_blank">www.pwpconsult.com</a> |                - Jeff Frantz | Los Gatos, CA 95032<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/<u></u>mailman/listinfo/cryptography</a></div></div></blockquote></div><br></div></div>