<div dir="ltr"><div>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.</div><div><br></div>The current custom extension API has a few issues that make it very difficult to use:<div><br></div><div>- There is no way to save data in the session state</div><div>- Custom extensions are not negotiated on resumption (how do we know what we negotiated originally?)</div><div>- It is not possible to know anything about other extensions that may or may not have been negotiated</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>What are the chances that the OpenSSL devs would be interested in upgrading this API?</div><div><br></div><div>Bill</div></div>