[openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change

[David Benjamin]

On Wed, Jan 30, 2019 at 11:20 AM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote:
> >
> >
> > On 29/01/2019 19:27, David Benjamin wrote:
> > > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <kurt at roeckx.be
> > > <mailto:kurt at roeckx.be>> wrote:
> > >
> > >     On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote:
> > >     > So I plan to start the vote soon for merging PR#8096 and
> backporting it to
> > >     > 1.1.1. This is a breaking change as previously discussed.
> > >     >
> > >     > My proposed vote text is as follows. Please let me know asap of
> any feedback.
> > >     > Otherwise I will start the vote soon.
> > >     >
> > >     > "master and 1.1.1 will be updated to use
> SSL_CB_POST_HANDSHAKE_START and
> > >     > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post
> handshake
> > >     > message exchange in the info callback (replacing
> SSL_CB_HANDSHAKE_START and
> > >     > SSL_CB_HANDSHAKE_END)."
> > >
> > >
> > > What exactly is a post-handshake message exchange? Do the
> NewSessionTicket sent
> > > by the server at the beginning count as the part of the handshake? Are
> they each
> > > separate post-handshake exchanges? Are all of them together one
> exchange?
> > > Conversely, what happens when you receive that NewSessionTicket as a
> client?
> >
> >
> > They are each separate post-handshake exchanges. Both on the server and
> on the
> > client.
> >
> > >
> > > When you send a KeyUpdate with key_update_requested, is the reply you
> expect
> > > part of the exchange or separate? What if the peer coalesced them to
> avoid DoS
> > > problems? Conversely, if you receive a KeyUpdate with
> key_update_requested, is
> > > your reply part of the exchange? What if you coalesced them to avoid
> DoS problems?
> > >
> > > What if I send a CertificateRequest, but the other side sends me a
> KeyUpdate
> > > with key_update_requested before responding with Certificate, so I
> respond with
> > > my own KeyUpdate? What and how many exchanges are there?
> > >
> > > Is it important that both sides agree what an "exchange" is?
> >
> > The answers all depend on how the OpenSSL state machine views them. At
> the
> > moment the peer sending a KeyUpdate sees that as a single standalone
> exchange.
> > If an update has been requested then the receiving peer sees the
> receiving and
> > subsequent sending of the next KeyUpdate as a single exchange.
>
> This "at the moment" sounds a lot like "we can change this at any
> time, for whatever reason".
>

Indeed, this is the whole reason we are in this mess right now.

"How OpenSSL's state machine views these events" is fundamentally not a
workable API definition. In OpenSSL 1.1.0, OpenSSL had the
SSL_CB_HANDSHAKE_START API. The semantics were "what the OpenSSL state
machine thinks is a new handshake". This aligned with the natural
definition of a "handshake", so callers, quite naturally, used that to be
notified of handshakes.

Then OpenSSL made a purportedly backwards-compatible release in 1.1.1. It
added TLS 1.3, chose a particular implementation strategy and made the
SSL_CB_HANDSHAKE_START semantics mirror the existing "what the OpenSSL
state machine thinks is a new handshake" semantics. But now it does not
align with the natural definition of a handshake. Indeed the response above
demonstrates there is no such natural definition that covers post-handshake
messages. The result is OpenSSL 1.1.1 subtly broke existing code, in a way
that damaged the TLS 1.3 ecosystem.

We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can
at least help slow its spread by issuing a fix and announcing to all
consumers (e.g. Linux distros) they need to take the fix. In doing so, it
is important to understand the root cause so that this mistake does not
repeat.

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.


> I can actually see a use case for wanting to know if a key update
> has been received and sent. Maybe the application wants to make
> sure that at regular intervals this is done. I just doubt that
> this is the most useful interface for that. The way to do that is
> to tell OpenSSL to do that instead.
>
> > Certificate requests are similar, i.e. the server sees the sending of the
> > certificate request as a single standalone exchange, and the receipt of
> the
> > subsequent Certificate/Finished as a separate exchange. The client sees
> the
> > receipt of the request and its response as one single exchange.
>
> I think the server really only cares that it's been received, and
> you can argue that it should be 1 exchange.
>
>
> Kurt
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190131/ea9ee184/attachment.html>