<div dir="ltr">Sorry... stupid auto-send still happens on my Goobuntu latptop, even with tap-click disabled on the still poorly supported touchpad.<div><br></div><div>Here's the current PR:  <a href="https://github.com/openssl/openssl/pull/1538">https://github.com/openssl/openssl/pull/1538</a></div><div><br></div><div>My feeling is that if we put in the effort to upgrade the new SSL test harness to understand custom extensions, it might also be a good time to upgrade the custom extension API.  There are a couple of enhancements that likely have been considered here before:</div><div><br></div><div>-  Add a way for custom extensions to save/restore state to the streamed session</div><div>- Add a way for custom extensions to see what other extensions have been negotiated or not.</div><div><br></div><div>Right now, custom extensions cannot save state between connections.  This makes many simple extensions impossible to implement using the custom extension API.  Often the server needs to remember the outcome of the original extension negotiation.</div><div><br></div><div>Another issue is that custom extensions get zero knowledge of other extensions.  This makes some things hard to implement.  For example, we would like to stop including a version field in the token binding extension, and instead just issue a new extension if the binary format needs to be updated in an incompatible way.  What happens if version 1.0 gets rewritten as a native extension, and we later write a new custom extension to override it?  Right now, there is no way to do that, giving weight to the argument for keeping the version number in the extension.  It is also not possible to ensure that extended-master-secret has been negotiated before the server add-callback has to commit to sending the token-binding extension in the server hello, meaning the client must check both extensions after the handshake completes, which is a bit goofy.</div><div><br></div><div>So, what would you think about going forward with a simple upgrade similar to my PR, while working out what an improved custom extension API should look llike?</div><div><br></div><div>Bill</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 5, 2016 at 7:12 PM, Bill Cox <span dir="ltr"><<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I took a quick look through the new SSL test framework, which looks pretty good.  I created this pull request to show what I currently propose:<div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 5, 2016 at 2:22 PM, Richard Levitte <span dir="ltr"><<a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it makes more sense to extend the new SSL test framework...<br>
<br>
Cheers<br>
Richard<br>
<br>
Bill Cox <<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>> skrev: (5 september 2016 19:14:22 CEST)<br>
<div><div>>I wrote a simple change to custom extensions so that they can be<br>
>negotiated<br>
>on resume, which is needed by token binding.  I put the test for this<br>
>change in test/ssltest_old.c, which seems weird, but there are no<br>
>custom<br>
>extension tests in the new SSL tests AFAIK.  Do we still extend the old<br>
>tests when there are no equivalent new tests?<br>
><br>
>Bill<br>
><br>
><br>
</div></div>>-----------------------------<wbr>------------------------------<wbr>-------------<br>
<span><font color="#888888"><br>
--<br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.<br>
--<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailma<wbr>n/listinfo/openssl-dev</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>