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

[David Benjamin]

On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <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?

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?

What I'm getting at here is that "post-handshake exchange" does not seem to
be a meaningful construct to the protocol. I would thus advocate not
signaling START/END things to begin with. That way, if TLS 1.4 comes by and
shuffles around again, we don't repeat this adventure.

I think one clear conclusion from this incident is that this sort of
low-level API should be avoided, or people will use them in finicky ways
that break unexpectedly when you change things. Better defer such
mechanisms to when concrete use cases come up, and then implement direct
APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback
hadn't existed, OpenSSL would hopefully have learned sooner that
SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided
today's TLS 1.3 KeyUpdate intolerance in the ecosystem.)


> This will only cover the key update currently? Does that come with
> some parameter telling which kind of handshake is happening? If
> not, is it more useful to just say that a key update is happening?
>

There's already a message callback. Why not just use that? It's unclear to
me why anyone would want to know when KeyUpdates happen anyway, aside from
low-level logging and debugging. The message callback works fairly well for
such things.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190129/a9b0e27b/attachment.html>