[openssl-dev] Future of custom extension API?

[Bill Cox]

Hi, folks.  I am a big fan of the concept of the custom extension API, but
it needs a bit of work.  If it were a bit more usable, I think we could
move a lot of simple extensions into this framework, simplifying OpenSSL.
In particular, I feel that managing complexity in OpenSSL is the single
biggest challenge for security.

The current custom extension API has a few issues that make it very
difficult to use:

- There is no way to save data in the session state
- Custom extensions are not negotiated on resumption (how do we know what
we negotiated originally?)
- It is not possible to know anything about other extensions that may or
may not have been negotiated

Because we do not have a way to remember what was originally negotiated,
the custom extension API is generally not usable for extensions that need
to either be remembered across resumption, or renegotiated.  As a minimal
patch, changing 1 so that custom extensions are negotiated on resumption
makes the API much more usable.  However, if we need to modify this API,
should we expand on it while we are at it?

I would be interested in helping to expand the API so that we could save
session state, specify what to do on resumption, and learn about other
extensions.  Since we already add custom extensions after native
extensions, it seems like it would be easy to allow the custom extension
API to at least know which native extensions are present.  If we add custom
extensions in order of their extension number, we could also know about
those.  Adding state to the session sounds pretty scary, at least with the
1.0 code I worked with, but there are various cases where it might be
needed.  For examle, Nick Harper's proposal for TLS 1.3 0-RTT Token Binding
requires that the server remember the key parameters negotiated on the
1-RTT handshake.  Even if I get my proposed 1-line change to enable custom
extensions on resumption, it looks like we'll still have to bake-in token
binding as a custom extension for TLS 1.3, unless we upgrade the API.

What are the chances that the OpenSSL devs would be interested in upgrading
this API?

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161111/993cc438/attachment.html>