On Tue, Nov 15, 2016 at 12:58 AM Bill Cox <waywardg...@gmail.com> wrote:
> On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <rs...@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, > Slight clarification: my proposal wasn't to save the extension from the peer, but to save the server's extension. 0-RTT rules are what they are because the server's response must be predicted, and you decline 0-RTT on a prediction miss. It implicitly predicts what the server did last time, so the only operation you need to support is "did the server pick the same thing as last time" which, for most extensions which follow the client offer / server pick pattern, like ALPN or tokbind, is the same as saying "is the server extension byte-for-byte identical?" That said, after discussing this with you, I realized there's a hole in my theory. Suppose we defined ALPN2 which is like ALPN but, rather than the server echoing the protocol, the server gave you an index into the client list. Then saving the server extension isn't sufficient and context from the client extension is needed. So, depending on what exactly you want this custom extension to support, you may want a more complex API surface. Though the saved server extension one should be suitable for all but really weird stuff. (1.3 pre_shared_key uses an index because echoing the ticket would be messy, but pre_shared_key is already very non-generically integrated with 0-RTT since it's session resumption.) David
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
