<div dir="ltr"><span style="font-size:12.800000190734863px">> Handshake payloads are (often) encrypted, so making them extensible is</span><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">> maybe less about middleboxes and more about not painting yourself into</span><br style="font-size:12.800000190734863px"><span style="font-size:12.800000190734863px">> a corner where you'd like to extend your protocol but can't.</span><br style="font-size:12.800000190734863px"><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">This related comment on SSHv2 is interesting as well: </span><a href="https://www.reddit.com/r/crypto/comments/7mii6w/why_tls_13_isnt_in_browsers_yet/drubr3j/">https://www.reddit.com/r/crypto/comments/7mii6w/why_tls_13_isnt_in_browsers_yet/drubr3j/</a></div><div><br></div><div>> Similar rusting has happened in SSH v2 and has required "innovative 
approaches" (e.g. using a field not originally intended for this 
purpose) to add an <a href="https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-15">extension mechanism</a><span class="gmail-noCtrlF gmail-keyNavAnnotation" title="press 1 to open link"></span>. The original extension field in SSH_MSG_KEXINIT cannot be used because even though the spec <a href="https://tools.ietf.org/html/rfc4253#section-7.1">defined it this way</a><span class="gmail-noCtrlF gmail-keyNavAnnotation" title="press 2 to open link"></span>:<br></div><div>

<pre><code>> uint32       0 (reserved for future extension)
</code></pre>

<p>> ... some implementations misinterpreted this and are not only sending a 0, but also <em>checking</em>
 that they receive a 0 (mighty support for "future extension"!). Another
 doesn't make an explicit check but assumes it's 0 and miscalculates the
 key exchange if it's not.</p></div><div><br></div><div>David</div></div>