[openssl-dev] Future of custom extension API?

[Bill Cox]

On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <rsalz at akamai.com> wrote:

> > What are the chances that the OpenSSL devs would be interested in
> upgrading this API?
>
> Pretty good.
>
> 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?
>

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.

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.

That, plus an API to examine the hello message or something like that seems
like it might do the trick,

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161114/9d9624ed/attachment.html>