<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 31/01/2019 18:50, David Benjamin wrote:<br>
> We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can at<br>
> least help slow its spread by issuing a fix<br>
<br>
That's precisely what PR 8096 does.<br>
<br>
<br>
> As a heuristic for API design: if the caller needs to know the implementation<br>
> details of OpenSSL to understand what this API does, the API is no good.<br>
> Existing code cannot possibly predict how OpenSSL's implementation will evolve<br>
> over time, so there is no way to use such an API in a future-proof way. Do not<br>
> introduce such APIs.<br>
<br>
The info callback has been around a *long* time. In fact OpenSSL did not<br>
introduce it at all - we inherited it from SSLeay. Arguments about whether it is<br>
a good API or not don't help the issue at hand. The API exists, applications use<br>
it, and so (for now at least) we continue to support it.<br>
<br>
Given that it already existed we had to make a decision about how it was going<br>
to work in the presence of TLSv1.3. We did what we believed to be the correct<br>
thing at the time. The changes were pretty minimal and we tried to keep things<br>
as close to what existing users of the callback would expect. It turns out we<br>
got it wrong.<br></blockquote><div><br></div><div>Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are new. It seems best to just omit it, so OpenSSL is not tied to the nebulous notion of "post-handshake exchange".</div><div><br></div><div>I.e. don't bracket post-handshake things with START/END at all.</div><div><br></div><div>David</div></div></div>