<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 17, 2017 at 6:09 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * Suppose the client wants to offer three new ciphers (version 1-3)<br>
but reuse the version 0 DH.  The client can send version indicators<br>
for 1-3, each followed by a zero-length message, reusing the version 0<br>
message's ephemeral public value.<br></blockquote><div><br></div><div>I would put a limit on how many versions can be offered.<br></div><div><br>I monitor the cryptography list and there's been lots of discussion on version/ciphersuite negotiation over the years.  One
 point of view (Ian G's I think) is one I agree with.  I'll try to summarise (apologies to the original authors if I get this wrong).<br><br>The protocol only supports 
two "versions": the current recommended one and a fallback.  For example, Noise_XX_25519_ChaChaPoly_SHA256 and Noise_XX_448_AESGCM_BLAKE2b.  The fallback is selected to have ridiculous security compared to the recommended.<br><br></div><div>The purpose of this is to limit rollback attacks and to make upgrading to new ciphersuites possible.  In the first protocol, implementations only support versions 0 and 1 and prefer to use 0.  But they can use 1 if the other side refuses 0.<br><br></div><div>This makes it possible to upgrade ciphersuites over time.  If version 0 falls to an attack, version 2 is defined and then implementations replace their 0/1 implementation with a 1/2 implementation.  This allows for emergency switch off of a broken ciphersuite and a clear migration path.<br><br></div><div>This could be extended to three or four overlapping "versions", but my main point is that the version window needs to be small to avoid situations where a rogue man-in-the-middle can force everyone back to Noise_XX_Broken2017 years from now (a la RC4 in SSL/TTLS).<br></div><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br></div></div><br></div></div>