<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 15, 2016 at 12:58 AM Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <span dir="ltr" class="gmail_msg"><<a href="mailto:rsalz@akamai.com" class="gmail_msg" target="_blank">rsalz@akamai.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="gmail_msg">> What are the chances that the OpenSSL devs would be interested in upgrading this API?<br class="gmail_msg">
<br class="gmail_msg">
</span>Pretty good.<br class="gmail_msg">
<br class="gmail_msg">
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 class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That, plus an API to examine the hello message or something like that seems like it might do the trick,</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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?"</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>David</div></div></div>