[openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
matt at openssl.org
Wed Jan 30 10:44:12 UTC 2019
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
> 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.
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.
> 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.
If we signal them at all then I think they must be signalled with start/end
since there can be multiple state changes for a single exchange (e.g. when the
client receives a certificate request).
More information about the openssl-project