On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote: > > > On 29/01/2019 19:27, David Benjamin wrote: > > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx <[email protected] > > <mailto:[email protected]>> 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.
This "at the moment" sounds a lot like "we can change this at any time, for whatever reason". I can actually see a use case for wanting to know if a key update has been received and sent. Maybe the application wants to make sure that at regular intervals this is done. I just doubt that this is the most useful interface for that. The way to do that is to tell OpenSSL to do that instead. > 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. I think the server really only cares that it's been received, and you can argue that it should be 1 exchange. Kurt _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
