On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote: > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <k...@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 _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project