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

2019-01-30 Thread Matt Caswell



On 30/01/2019 17:20, Kurt Roeckx wrote:
> On Wed, Jan 30, 2019 at 10:44:12AM +, Matt Caswell wrote:
>>
>>
>> On 29/01/2019 19:27, David Benjamin wrote:
>>> On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx >> > wrote:
>>>
>>> On Tue, Jan 29, 2019 at 02:07:09PM +, 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".

No, it means that is how it currently coded. We are discussing a PR to change
how this works so we have the opportunity to make it work differently if we so
wish. However since this is a breaking change I'm of the view that we should be
making the minimal change necessary. IMO that is the change that I have proposed
in PR 8096 and as described in the vote text at the beginning of this thread.

I don't think we should be looking at this as a wholesale redesign of how the
info callback works and its relative merits an disadvantages. Like it or not we
have an info callback, and it does what it does. It is in our API and we cannot
remove it (at least not any time soon - see
https://github.com/openssl/web/pull/82). We implemented it in a particular way
for TLSv1.3 and if we wanted something else then the time to debate that was
prior to the release of 1.1.1. The *only* reason that this is being discussed
now is because of the specific issue with KeyUpdates. PR8096 fixes that in the
simplest way I could think of.


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

I'm not entirely sure what you mean by "1 exchange", but if you mean the sending
of the request and the subsequent receipt of the certificate/finished should be
1 exchange as far as the info callback is concerned then I don't think that
would work. There may be intervening messages and application data transfer.

Matt





___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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

2019-01-30 Thread Kurt Roeckx
On Wed, Jan 30, 2019 at 10:44:12AM +, Matt Caswell wrote:
> 
> 
> On 29/01/2019 19:27, David Benjamin wrote:
> > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx  > > wrote:
> > 
> > On Tue, Jan 29, 2019 at 02:07:09PM +, 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


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

2019-01-30 Thread Benjamin Kaduk
On Wed, Jan 30, 2019 at 09:02:30AM +0100, Kurt Roeckx wrote:
> On Tue, Jan 29, 2019 at 02:07:09PM +, 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)."
> 
> So my proposal would be: Don't call the callback for post
> handshake messages. (It could use some rewording.)

That does have a fair bit of appeal to it, though perhaps not enough to
justify the breaking change in 1.1.1.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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

2019-01-30 Thread Matt Caswell



On 29/01/2019 19:27, David Benjamin wrote:
> On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx  > wrote:
> 
> On Tue, Jan 29, 2019 at 02:07:09PM +, 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
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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

2019-01-30 Thread Matt Caswell



On 29/01/2019 17:31, Kurt Roeckx wrote:
> On Tue, Jan 29, 2019 at 02:07:09PM +, 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)."
> 
> 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?

The info callback calls SSL_CB_POST_HANDSHAKE_START, followed by a series of
SSL_CB_LOOP events for each state change of the state machine, followed by
SSL_CB_POST_HANDSHAKE_END. It is possible to query the state machine to find out
what kind of message we are currently processing. That's the way the callback
works for all other "initial" handshake messages.

The new SSL_CB_POST_HANDSHAKE_* events apply to all post-handshake message
exchanges - not just key update.

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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

2019-01-30 Thread Kurt Roeckx
On Tue, Jan 29, 2019 at 02:07:09PM +, 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)."

So my proposal would be: Don't call the callback for post
handshake messages. (It could use some rewording.)


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project