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

[Matt Caswell]

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.

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


Matt