[openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
David Benjamin
davidben at google.com
Thu Jan 31 20:19:28 UTC 2019
On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell <matt at openssl.org> wrote:
>
> On 31/01/2019 18:50, David Benjamin wrote:
> > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL
> can at
> > least help slow its spread by issuing a fix
>
> That's precisely what PR 8096 does.
>
>
> > As a heuristic for API design: if the caller needs to know the
> implementation
> > details of OpenSSL to understand what this API does, the API is no good.
> > Existing code cannot possibly predict how OpenSSL's implementation will
> evolve
> > over time, so there is no way to use such an API in a future-proof way.
> Do not
> > introduce such APIs.
>
> The info callback has been around a *long* time. In fact OpenSSL did not
> introduce it at all - we inherited it from SSLeay. Arguments about whether
> it is
> a good API or not don't help the issue at hand. The API exists,
> applications use
> it, and so (for now at least) we continue to support it.
>
> Given that it already existed we had to make a decision about how it was
> going
> to work in the presence of TLSv1.3. We did what we believed to be the
> correct
> thing at the time. The changes were pretty minimal and we tried to keep
> things
> as close to what existing users of the callback would expect. It turns out
> we
> got it wrong.
>
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".
I.e. don't bracket post-handshake things with START/END at all.
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190131/94995d04/attachment-0001.html>
More information about the openssl-project
mailing list