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

[Benjamin Kaduk]

On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> 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?

I don't think we should try to get into the business of demarcating the
start and end of post-handshake exchanges.  (In particular, the
NewSessionTickets are formally not grouped with anything, whether the
initial handshake or each other.)

> 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.

+1

> 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.

+1

-Ben