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 <k...@roeckx.be
> > <mailto: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?
> 
> 
> 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
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to