<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 29, 2014 at 7:10 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=trevp@trevp.net&cc=&bcc=&su=&body=','_blank');return false;">trevp@trevp.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think having *version* negotiation for an entire protocol is useful,<br>
so you can migrate to new versions which might include any change.<br>
I've been assuming that would be handled outside the noise core, i.e.<br>
the client might prefix its first message with a version number or<br>
something.<br>
<br>
But arguably we should do more to support versioning.  It would be<br>
good if anyone trying to create a "real" protocol around this could<br>
think about this and see what would work for them.</blockquote><div><br></div><div>+1 to versioning. Arguably this (i.e. cipher agility) doesn't happen very often. We may have just seen it with the move from RC4 -> AES-GCM, but even that was something of an oddity as it was precipitated by a move from AES -> RC4 due to TLS's lack of a Noise Box-like primitive and attacks like BEAST (so use an authenticated stream cipher and call it good?).</div>

<div><br></div><div>All that said, I would strongly be in favor of Noise having some mechanism for the server to signal the client that they're using a vulnerable protocol and that connections for the version they're attempting to use are unacceptable and they should upgrade. </div>

</div><div><br></div>-- <br>Tony Arcieri<br>
</div></div>