<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <span dir="ltr"><<a href="mailto:rsalz@akamai.com" target="_blank">rsalz@akamai.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="">> What are the chances that the OpenSSL devs would be interested in upgrading this API?<br>
<br>
</span>Pretty good.<br>
<br>
We’re looking at adding a new API for 1.1.1 that is like the one in boring -- it gives full acess to the hello message.  The 1.1.0 API is frozen.  But what can we do for the next release, while still keeping API compatibility?  That is, the existing API can't go away, but maybe the "better" one can be added?<br></blockquote><div><br></div><div>Sounds good to me.  David Benjamin had an idea I may be mis-interpreting, but instead of allowing custom extensions to save state directly to the streamed session blob, custom extensions that request it could have the response from the other side auto-saved for them.  That way, on a resume, if the server accepts the resume, the server-side custom extension would see the original data from the client, and if the resume is rejected, it would see the new extension data from the client.  I think the server is supposed to compare them and fall back to a full handshake if they are different, but David could confirm these details.</div><div><br></div><div>Similarly, client-side would see the original server response on a resume, and the new one if falling back to full handshake.  In this scheme, the server does not need to send custom extensions on resume, SFAIK.</div><div><br></div><div>That, plus an API to examine the hello message or something like that seems like it might do the trick,</div><div><br></div><div>Bill </div></div></div></div>