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

[Matt Caswell]

On 12/02/2019 10:08, Matt Caswell wrote:
> 
> 
> On 07/02/2019 15:03, Matt Caswell wrote:
>> That would make the proposed vote text for this OMC vote:
>>
>> "master and 1.1.1 will be updated so that they do not signal the start and 
>> end
>> of post-handshake message exchanges in the info callback using
>> SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE."
> 
> I started this vote and will report back on the results in due course.

This vote passed:

+1: 5
 0: 2
-1: 0

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

[Matt Caswell]

On 06/02/2019 23:11, Kurt Roeckx wrote:
> On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote:
>> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell  wrote:
>>
>>>
>>> On 31/01/2019 18:50, David Benjamin wrote:
 We will see if this damage turns out fatal for KeyUpdate, but OpenSSL
>>> can at
 least help slow its spread by issuing a fix
>>>
>>> That's precisely what PR 8096 does.
>>>
>>>
 As a heuristic for API design: if the caller needs to know the
>>> implementation
 details of OpenSSL to understand what this API does, the API is no good.
 Existing code cannot possibly predict how OpenSSL's implementation will
>>> evolve
 over time, so there is no way to use such an API in a future-proof way.
>>> Do not
 introduce such APIs.
>>>
>>> The info callback has been around a *long* time. In fact OpenSSL did not
>>> introduce it at all - we inherited it from SSLeay. Arguments about whether
>>> it is
>>> a good API or not don't help the issue at hand. The API exists,
>>> applications use
>>> it, and so (for now at least) we continue to support it.
>>>
>>> Given that it already existed we had to make a decision about how it was
>>> going
>>> to work in the presence of TLSv1.3. We did what we believed to be the
>>> correct
>>> thing at the time. The changes were pretty minimal and we tried to keep
>>> things
>>> as close to what existing users of the callback would expect. It turns out
>>> we
>>> got it wrong.
>>>
>>
>> Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are
>> new. It seems best to just omit it, so OpenSSL is not tied to the nebulous
>> notion of "post-handshake exchange".
>>
>> I.e. don't bracket post-handshake things with START/END at all.
> 
> Matt, do you have any comment on this? Can we go forward with
> this?

I'm not particularly keen on not signalling at all. But its also "not a hill I'm
going to die on". So I updated #8096 accordingly.

That would make the proposed vote text for this OMC vote:

"master and 1.1.1 will be updated so that they do not signal the start and end
of post-handshake message exchanges in the info callback using
SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE."

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

[Kurt Roeckx]

On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote:
> On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell  wrote:
> 
> >
> > On 31/01/2019 18:50, David Benjamin wrote:
> > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL
> > can at
> > > least help slow its spread by issuing a fix
> >
> > That's precisely what PR 8096 does.
> >
> >
> > > As a heuristic for API design: if the caller needs to know the
> > implementation
> > > details of OpenSSL to understand what this API does, the API is no good.
> > > Existing code cannot possibly predict how OpenSSL's implementation will
> > evolve
> > > over time, so there is no way to use such an API in a future-proof way.
> > Do not
> > > introduce such APIs.
> >
> > The info callback has been around a *long* time. In fact OpenSSL did not
> > introduce it at all - we inherited it from SSLeay. Arguments about whether
> > it is
> > a good API or not don't help the issue at hand. The API exists,
> > applications use
> > it, and so (for now at least) we continue to support it.
> >
> > Given that it already existed we had to make a decision about how it was
> > going
> > to work in the presence of TLSv1.3. We did what we believed to be the
> > correct
> > thing at the time. The changes were pretty minimal and we tried to keep
> > things
> > as close to what existing users of the callback would expect. It turns out
> > we
> > got it wrong.
> >
> 
> Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are
> new. It seems best to just omit it, so OpenSSL is not tied to the nebulous
> notion of "post-handshake exchange".
> 
> I.e. don't bracket post-handshake things with START/END at all.

Matt, do you have any comment on this? Can we go forward with
this?


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

[Matt Caswell]

On 31/01/2019 18:50, David Benjamin wrote:
> We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can at
> least help slow its spread by issuing a fix

That's precisely what PR 8096 does.


> As a heuristic for API design: if the caller needs to know the implementation
> details of OpenSSL to understand what this API does, the API is no good.
> Existing code cannot possibly predict how OpenSSL's implementation will evolve
> over time, so there is no way to use such an API in a future-proof way. Do not
> introduce such APIs.

The info callback has been around a *long* time. In fact OpenSSL did not
introduce it at all - we inherited it from SSLeay. Arguments about whether it is
a good API or not don't help the issue at hand. The API exists, applications use
it, and so (for now at least) we continue to support it.

Given that it already existed we had to make a decision about how it was going
to work in the presence of TLSv1.3. We did what we believed to be the correct
thing at the time. The changes were pretty minimal and we tried to keep things
as close to what existing users of the callback would expect. It turns out we
got it wrong.

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

[David Benjamin]

On Wed, Jan 30, 2019 at 11:20 AM 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".
>

Indeed, this is the whole reason we are in this mess right now.

"How OpenSSL's state machine views these events" is fundamentally not a
workable API definition. In OpenSSL 1.1.0, OpenSSL had the
SSL_CB_HANDSHAKE_START API. The semantics were "what the OpenSSL state
machine thinks is a new handshake". This aligned with the natural
definition of a "handshake", so callers, quite naturally, used that to be
notified of handshakes.

Then OpenSSL made a purportedly backwards-compatible release in 1.1.1. It
added TLS 1.3, chose a particular implementation strategy and made the
SSL_CB_HANDSHAKE_START semantics mirror the existing "what the OpenSSL
state machine thinks is a new handshake" semantics. But now it does not
align with the natural definition of a handshake. Indeed the response above
demonstrates there is no such natural definition that covers post-handshake
messages. The result is OpenSSL 1.1.1 subtly broke existing code, in a way
that damaged the TLS 1.3 ecosystem.

We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can
at least help slow its spread by issuing a fix and announcing to all
consumers (e.g. Linux distros) they need to take the fix. In doing so, it
is important to understand the root cause so that this mistake does not
repeat.

As a heuristic for API design: if the caller needs to know the
implementation details of OpenSSL to understand what this API does, the API
is no good. Existing code cannot possibly predict how OpenSSL's
implementation will evolve over time, so there is no way to use such an API
in a future-proof way. Do not introduce such APIs.


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

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

[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

[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

[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

[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

[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

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

[Benjamin Kaduk]

On Tue, Jan 29, 2019 at 01:27:24PM -0600, 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?

I don't think we should try to get into the business of demarcating the
start and end of post-handshake exchanges.  (In particular, the
NewSessionTickets are formally not grouped with anything, whether the
initial handshake or each other.)

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

+1

> I think one clear conclusion from this incident is that this sort of
> low-level API should be avoided, or people will use them in finicky ways
> that break unexpectedly when you change things. Better defer such
> mechanisms to when concrete use cases come up, and then implement direct
> APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback
> hadn't existed, OpenSSL would hopefully have learned sooner that
> SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided
> today's TLS 1.3 KeyUpdate intolerance in the ecosystem.)
> 
> 
> > 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?
> >
> 
> There's already a message callback. Why not just use that? It's unclear to
> me why anyone would want to know when KeyUpdates happen anyway, aside from
> low-level logging and debugging. The message callback works fairly well for
> such things.

+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

[Kurt Roeckx]

On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> I think one clear conclusion from this incident is that this sort of
> low-level API should be avoided, or people will use them in finicky ways
> that break unexpectedly when you change things. Better defer such
> mechanisms to when concrete use cases come up, and then implement direct
> APIs for those use cases, like SSL_OP_NO_RENEGOTIATION.

I have to agree to that.


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

[David Benjamin]

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?

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?

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.

I think one clear conclusion from this incident is that this sort of
low-level API should be avoided, or people will use them in finicky ways
that break unexpectedly when you change things. Better defer such
mechanisms to when concrete use cases come up, and then implement direct
APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback
hadn't existed, OpenSSL would hopefully have learned sooner that
SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided
today's TLS 1.3 KeyUpdate intolerance in the ecosystem.)


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

There's already a message callback. Why not just use that? It's unclear to
me why anyone would want to know when KeyUpdates happen anyway, aside from
low-level logging and debugging. The message callback works fairly well for
such things.

David
___
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

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

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?


Kurt

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

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

[Matt Caswell]

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


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