Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Matt Caswell]

On 28/01/2019 21:18, Kurt Roeckx wrote:
> On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote:
>>
>>
>> On 24/01/2019 18:12, Sam Roberts wrote:
>>> The other changes that TLS1.3 requires, multiple session tickets, a
>>> few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
>>> all are pretty routine. We could get TLS1.3 support in Node.js fairly
>>> quickly if the info callback issue was solved openssl side. I'm even
>>> happy to help work on it if that's an issue, it would be more
>>> productive than what I've been trying to do in Node.js.
>>
>> In case anyone missed it I opened a PR for this over the weekend:
>>
>> https://github.com/openssl/openssl/pull/8096
>>
>> I'm leaving it there for a day or two for people to comment. Assuming no 
>> major
>> issues are identified I'll will raise an OMC vote for it.
> 
> Can I suggest you just describe what the patch does, and call a
> vote on that?

Sure. I'll post the proposed text for comment before I call the vote anyway.

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Kurt Roeckx]

On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote:
> 
> 
> On 24/01/2019 18:12, Sam Roberts wrote:
> > The other changes that TLS1.3 requires, multiple session tickets, a
> > few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
> > all are pretty routine. We could get TLS1.3 support in Node.js fairly
> > quickly if the info callback issue was solved openssl side. I'm even
> > happy to help work on it if that's an issue, it would be more
> > productive than what I've been trying to do in Node.js.
> 
> In case anyone missed it I opened a PR for this over the weekend:
> 
> https://github.com/openssl/openssl/pull/8096
> 
> I'm leaving it there for a day or two for people to comment. Assuming no major
> issues are identified I'll will raise an OMC vote for it.

Can I suggest you just describe what the patch does, and call a
vote on that?


Kurt

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Matt Caswell]

On 24/01/2019 18:12, Sam Roberts wrote:
> The other changes that TLS1.3 requires, multiple session tickets, a
> few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
> all are pretty routine. We could get TLS1.3 support in Node.js fairly
> quickly if the info callback issue was solved openssl side. I'm even
> happy to help work on it if that's an issue, it would be more
> productive than what I've been trying to do in Node.js.

In case anyone missed it I opened a PR for this over the weekend:

https://github.com/openssl/openssl/pull/8096

I'm leaving it there for a day or two for people to comment. Assuming no major
issues are identified I'll will raise an OMC vote for it.

Matt

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Sam Roberts]

I appreciate that there are multiple ways of looking at this, but I
don't think that looking at the info callback from the point of view
of "is it or is it not a handshake record" is pragmatic. The
SSL_set_msg_callback could be used by people wanting to see all the
underlying records.

The way the info callbacks are behaving for TLS1.3 is a major obstacle
to Node.js supporting TLS1.3. The intention of 1.1.1 was to make
TLS1.3 support as painfree as possible, and it doesn't seem to be
doing that. When it was just Node.js that was having to work around
this, I was convinced that we had some kind of historical abuse of the
info callback we would just have to fix. Now that I hear that (at
least) haproxy and nginx are also affected, I'd appreciate a
reconsideration of this from the purely pragmatic point of view of
"how do we make TLS1.3 support easy to achieve", the ultimate goal
here for everyone (I think!).

The behaviour of the info callbacks is already backwards incompatible
with openssl 1.1.0, even for TLS1.2
(https://github.com/openssl/openssl/issues/7199). For API users
wanting to detect ticket exchange, HelloRequest, and other "handshake"
records with the info callbacks, changing to use different "where"
values would not be as disruptive as the affect is on users trying to
detect handshake start/done via callback. If I am underestimating how
disruptive that is, its not out of the question to have a
"compatibility" mode where the info callbacks change their behaviour
based on how the context is set up No one likes having to support
these kinds of flags, but it would remove concerns about introducing
breaking changes in the 1.1.1 line if they were opt-in, so this
doesn't become a question of "who's code do we break".

Its also not clear whether all uses of the info callback actually have
another API alternatives.

We use the info callbacks to reject renegotiation. Apparently there is
an option to do this now with a mode, so we could likely adopt that
way.

We use the info callbacks to time renegotiations, and reject them if
they take too long. I'm not aware of any other API that would allow us
to do this.

We  use the info callbacks to detect when renegotiation has been
requested on an existing connection, and inform node API users. I'm
not aware of any other API that would allow us to  do that.

Changing from using the info callbacks to get notified of start/done
of the initial handshake using SSL_do_handshake() (or
SSL_connect/SSL_accept) is theoretically possible, but turns out to be
easy to say, and has been much harder to do. The interactions with
node.js internal stream and async mechanisms are subtle, and after
close to a week of concerted effort, I still haven't gotten it working
(some things work, some don't, its been a discouraging game of
whack-a-bug). It can't be impossible, but its the type of substantial
rewrite necessary to support TLS1.3 that ideally would not be
necessary.

The other changes that TLS1.3 requires, multiple session tickets, a
few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
all are pretty routine. We could get TLS1.3 support in Node.js fairly
quickly if the info callback issue was solved openssl side. I'm even
happy to help work on it if that's an issue, it would be more
productive than what I've been trying to do in Node.js.

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Tim Hudson]

On Thu, Jan 24, 2019 at 9:45 PM Matt Caswell  wrote:

> > This notion of "handshake" is not supported by RFC 8446 uses the terms
> "the
> > handshake", "a handshake", and "post-handshake". "Post-handshake", in
> > particular, implies KeyUpdate are after the handshake, not part of it.
>
> I just don't agree with you here. About the best that can be said about
> RFC8446
> in this regards is that the term handshake is overloaded. It certainly
> does mean
> "the initial handshake" in the way that you describe (and I myself use the
> term
> to mean that). But it is *also* used in other contexts, such as "handshake
> messages" or "handshake protocol" where it is referring to things not
> necessarily constrained to the initial handshake.
>

I agree with Matt here - there is no such clear distinction made in RFC8446
- with "handshake" being used in *all *contexts.
If such a distinction was intended by the IETF WG then they failed to
achieve it in RFC8446 in numerous places.

Quoting RFC8446 ...

4.6.3.  Key and Initialization Vector Update

   The KeyUpdate *handshake message ...*


It doesn't help that it has 4.6 Post-Handshake Message section which states
"after the main handshake" also indicating that the handshake messages are
handshakes too - just not the "main handshake".

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Matt Caswell]

On 23/01/2019 18:29, Viktor Dukhovni wrote:
>  I should also note that there are two
> issues in this thread, of which this is the second.  The first one is about
> the limit on the number of key update messages per connection, and I hope
> that we can do something sensible there with less controversy.
> 

I don't consider that aspect to be controversial - although we do need to give
some thought to what the right fix looks like.

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Matt Caswell]

On 23/01/2019 17:42, David Benjamin wrote:
> On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell  > wrote:
> 
> On 22/01/2019 20:41, David Benjamin wrote:
> > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni
> mailto:openssl-us...@dukhovni.org>
> > >>
> wrote:
> >     As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite 
> sure
> >     what to do there, but perhaps we could define a new even for 
> keyUpdates
> >     that does not mislead applications into assuming a new "handshake".
> >
> > I think this is clearly the right option. This is a compatibility 
> break, IMO.
> >
> > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 
> 1.3),
> this
> > was the only way to disable renegotiations. I've seen a lot of 
> codebases do
> > this. I don't think one could even call it a mishandling. The natural
> > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has 
> started.
> > Thus, if you wish to block renegotiations, absent a more direct API, 
> it's
> > natural to count those and fail if you see more than one.
> >
> > A KeyUpdate is not a handshake.
> 
> That's depends on your perspective. One peer sends a message, and the 
> other peer
> (may) respond with a message. Sounds like a handshake to me. KeyUpdate 
> gets sent
> in handshake records, with a HandshakeType value of 24 and is defined in 
> section
> 4 of the RFC ("Handshake Protocol").
> 
> 
> This notion of "handshake" is not supported by RFC 8446 uses the terms "the
> handshake", "a handshake", and "post-handshake". "Post-handshake", in
> particular, implies KeyUpdate are after the handshake, not part of it.

I just don't agree with you here. About the best that can be said about RFC8446
in this regards is that the term handshake is overloaded. It certainly does mean
"the initial handshake" in the way that you describe (and I myself use the term
to mean that). But it is *also* used in other contexts, such as "handshake
messages" or "handshake protocol" where it is referring to things not
necessarily constrained to the initial handshake.

Ignoring the unexpected interaction with KeyUpdates for the moment, it seems
perfectly reasonable to me to use the SSL_CB_HANDSHAKE_START event to indicate
"we are about to exchange handshake messages" - whether or not that is in the
context of the initial handshake or not.

> This documentation does not help code written prior to TLSv1.3, which is the
> problem here. OpenSSL claims that TLS 1.3 is a backwards-compatible addition, 
> so
> documentation updates for 1.3 may clarify but cannot be necessary. More on 
> this
> below.

I agree with this. That is precisely what I think that documentation does.

> Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on
> KeyUpdate. Not signaling has some risk
> ,
> but it is low, especially in comparison to the known breakage and ecosystem
> damage caused by signaling.

Note: I have not said that we should not do this. All I have said is that
changing the events should be done with caution.

We do not (usually) allow breaking changes into stable releases - and with good
reason. 1.1.1 has been declared as an LTS release. At the same time both 1.1.0
and 1.0.2 have moved to "security fix only" mode. So we are actively encouraging
all users to move to that version. It's not a great message to send out if we
are changing documented behaviour in a letter release and it could break some
applications.

What that means in practice is that in order for that change to be accepted I
think it would require an OMC vote. I don't think the normal review process is
good enough since this change would be actively breaking policy and isn't a bug
fix (at least not in the usual sense of what that means).

If we decided to make the change then we would also need to consider what it
would mean for other message exchanges such as CertificateRequest and
HelloRequest (not sure what we do now with this last one). Would we only change
KeyUpdate (which would be a bit weird)? Or should we change all post-handshake
messages to be consistent (which might risk more breakage than is strictly
necessary to fix the KeyUpdate problem).

Matt


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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Viktor Dukhovni]

> On Jan 23, 2019, at 12:42 PM, David Benjamin  wrote:
> 
> (a) Debugging hooks for tracing, often copied from the openssl binary.
> (b) As a callback to know when the handshake (in the RFC8446 sense described 
> above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE.
> (c) As a callback to block renegotiations.
> 
> The problem here is (c), and empirically has affected versions of NGINX, 
> Node, HAProxy and the real TLS 1.3 ecosystem. There may be more yet 
> undiscovered problems; we only had KeyUpdates on in Chrome for a week on 
> Chrome Canary before we had to shut it off. At three affected callers, one 
> cannot simply say this is the consumer's fault.
> 
> As for the others, (b) also doesn't want to trigger on KeyUpdate, though it 
> may tolerate it. (I have seen versions of (b) which ignore duplicates and 
> versions which break on renegos---no one tests against it, which is why it's 
> off by default in BoringSSL.) (a) is closest to the scenario you are 
> concerned about, but such debugging notes are just that: debugging. I have 
> never seen code which cares about their particulars. Indeed, if it did, 
> adding TLS 1.3 would not be compatible because 1.3 changes the state machine.
> 
> Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on 
> KeyUpdate. Not signaling has some risk, but it is low, especially in 
> comparison to the known breakage and ecosystem damage caused by signaling.

I'm inclined to agree with David here.  I should also note that there are two
issues in this thread, of which this is the second.  The first one is about
the limit on the number of key update messages per connection, and I hope
that we can do something sensible there with less controversy.

-- 
Viktor.

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[David Benjamin]

On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell  wrote:

> On 22/01/2019 20:41, David Benjamin wrote:
> > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni <
> openssl-us...@dukhovni.org
> > > wrote:
> > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite
> sure
> > what to do there, but perhaps we could define a new even for
> keyUpdates
> > that does not mislead applications into assuming a new "handshake".
> >
> > I think this is clearly the right option. This is a compatibility break,
> IMO.
> >
> > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added
> 1.3), this
> > was the only way to disable renegotiations. I've seen a lot of codebases
> do
> > this. I don't think one could even call it a mishandling. The natural
> > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has
> started.
> > Thus, if you wish to block renegotiations, absent a more direct API, it's
> > natural to count those and fail if you see more than one.
> >
> > A KeyUpdate is not a handshake.
>
> That's depends on your perspective. One peer sends a message, and the
> other peer
> (may) respond with a message. Sounds like a handshake to me. KeyUpdate
> gets sent
> in handshake records, with a HandshakeType value of 24 and is defined in
> section
> 4 of the RFC ("Handshake Protocol").
>

This notion of "handshake" is not supported by RFC 8446 uses the terms "the
handshake", "a handshake", and "post-handshake". "Post-handshake", in
particular, implies KeyUpdate are after the handshake, not part of it.

KeyUpdate is also not quite a request/response pair. The caller is allowed
to coalesce consecutive key_update_requests
. This was done to avoid
DoS  and
allow a lighter strategy: if you see key_update_request on read, set a flag
and continue. When you make an outgoing record on write, if the flag is
set, queue a KeyUpdate up first and clear the flag. This avoids the DoS:
write overhead is bounded and read/write flows are independent.

Finally, compare with TCP socket APIs, which most applications have in
mind. There is a connect() phase that happens *once* at the start,
afterwards one calls read() and write(). During read() and write(), TCP
still ends other non-data packets, but those are abstracted away.


> To me it makes perfect sense to signal it this way. In fact it was a
> deliberate
> decision to do so and is documented accordingly:
>
>  =item SSL_CB_HANDSHAKE_START
>
>  Callback has been called because a new handshake is started. In TLSv1.3
> this is
>  also used for the start of post-handshake message exchanges such as for
> the
>  exchange of session tickets, or for key updates. It also occurs when
> resuming a
>  handshake following a pause to handle early data.
>
>  =item SSL_CB_HANDSHAKE_DONE   0x20
>
>  Callback has been called because a handshake is finished. In TLSv1.3 this
> is
>  also used at the end of an exchange of post-handshake messages such as for
>  session tickets or key updates. It also occurs if the handshake is paused
> to
>  allow the exchange of early data.
>

This documentation does not help code written prior to TLSv1.3, which is
the problem here. OpenSSL claims that TLS 1.3 is a backwards-compatible
addition, so documentation updates for 1.3 may clarify but cannot be
necessary. More on this below.


> Ironically it was done this way with a view to *avoiding* a compatibility
> break.
> The thinking was that applications written with TLSv1.2 in mind may find it
> surprising to start receiving events after the initial connection setup
> that are
> not enclosed in HANDSHAKE_START/HANDSHAKE_DONE. The info callback is
> intended as
> a tracing API IMO. It's only the fact that it has been used in ways other
> than
> we might have expected that we have this problem. In fact if your
> application is
> using the API to detect renegs because it wants to report when key updates
> are
> happening (rather than blocking them)well that application will
> continue to
> work and will stop working if we change the events.
>
> Given this is documented that way, some applications may already be using
> it -
> so changing the events now should be done with caution. That itself could
> cause
> a break. We know that this is causing some problems now because of the way
> that
> some applications are (mis)using this API. What we don't know is what new
> problems would surface if we changed its semantics in a letter release.
>
> Really the root of this problem is not in the info callback at all. It is
> the
> fact that in earlier 1.1.0 releases we did not have an effective way of
> blocking
> renegs. We now have SSL_OP_NO_RENEGOTIATION which is the "right" way to do
> this.
> I'd also note that this was backported to the 1.1.0 branch in 1.1.0h (March
> 2018) and so has been available to all 1.1.x users for some whi

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Matt Caswell]

On 22/01/2019 20:41, David Benjamin wrote:
> On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni  > wrote:
> 
> 
> 
> > On Jan 22, 2019, at 2:06 PM, Adam Langley  > wrote:
> >
> > (This is another installment of our experiences with deploying the
> > RFC-final TLS 1.3—previous messages: [1][2]. We share these with the
> > community to hopefully avoid other people hitting the same issues.)
> >
> > [...]
> >
> > However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3
> > post-handshake messages are received[5], including KeyUpdate. This
> > causes KeyUpdate messages to break with, at least, HAProxy, and with
> > NGINX prior to this commit[6]. (There may well be more, but that level
> > of breakage was enough to drown any other signal.)
> >
> > Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages
> > per connection[7]. Therefore clients that send periodic KeyUpdates
> > based on elapsed time or transmitted bytes will eventually hit that
> > limit, which is fatal to the connection.
> >
> > Therefore KeyUpdate messages are not currently viable on the web, at
> > least when client initiated.
> >
> > [1] 
> https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE
> > [2] 
> https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ
> > [3] https://bugs.openjdk.java.net/browse/JDK-8211806
> > [4] https://bugs.openjdk.java.net/browse/JDK-8213202
> > [5] https://github.com/openssl/openssl/issues/8069
> > [6]
> 
> https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c
> > [7] https://github.com/openssl/openssl/issues/8068
> > [8] https://twitter.com/__subodh/status/1085642001595265024
> 
> I think we should remediate the reported issues in the 1.1.1b release.
> We should probably clear the keyUpdate count when sufficient application
> data has been received from the peer.  Where sufficient could be as little
> as 1 byte, or could be something more reasonable (say 1MB, allowing for
> up to 32 rekeys per MB, which is plenty).
> 
> As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
> what to do there, but perhaps we could define a new even for keyUpdates
> that does not mislead applications into assuming a new "handshake".
> 
> 
> I think this is clearly the right option. This is a compatibility break, IMO.
> 
> Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 1.3), 
> this
> was the only way to disable renegotiations. I've seen a lot of codebases do
> this. I don't think one could even call it a mishandling. The natural
> interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has started.
> Thus, if you wish to block renegotiations, absent a more direct API, it's
> natural to count those and fail if you see more than one.
> 
> A KeyUpdate is not a handshake.

That's depends on your perspective. One peer sends a message, and the other peer
(may) respond with a message. Sounds like a handshake to me. KeyUpdate gets sent
in handshake records, with a HandshakeType value of 24 and is defined in section
4 of the RFC ("Handshake Protocol").

To me it makes perfect sense to signal it this way. In fact it was a deliberate
decision to do so and is documented accordingly:

 =item SSL_CB_HANDSHAKE_START

 Callback has been called because a new handshake is started. In TLSv1.3 this is
 also used for the start of post-handshake message exchanges such as for the
 exchange of session tickets, or for key updates. It also occurs when resuming a
 handshake following a pause to handle early data.

 =item SSL_CB_HANDSHAKE_DONE   0x20

 Callback has been called because a handshake is finished. In TLSv1.3 this is
 also used at the end of an exchange of post-handshake messages such as for
 session tickets or key updates. It also occurs if the handshake is paused to
 allow the exchange of early data.

Ironically it was done this way with a view to *avoiding* a compatibility break.
The thinking was that applications written with TLSv1.2 in mind may find it
surprising to start receiving events after the initial connection setup that are
not enclosed in HANDSHAKE_START/HANDSHAKE_DONE. The info callback is intended as
a tracing API IMO. It's only the fact that it has been used in ways other than
we might have expected that we have this problem. In fact if your application is
using the API to detect renegs because it wants to report when key updates are
happening (rather than blocking them)well that application will continue to
work and will stop working if we change the events.

Given this is documented that way, some applications may already be using it -
so changing the events now should be done with caution. That itself could cause
a break. We know tha

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Kurt Roeckx]

On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote:
> As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
> what to do there, but perhaps we could define a new even for keyUpdates
> that does not mislead applications into assuming a new "handshake".

I think calling anything a handshake that is not a handshake
should either be removed or renamed. KeyUpdate is not a handshake.
I'm not sure what we do in case of a session ticket, but it also
shouldn't send such events, but other events are probably useful
in that case.


Kurt

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

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

[Viktor Dukhovni]

> On Jan 22, 2019, at 2:06 PM, Adam Langley  wrote:
> 
> (This is another installment of our experiences with deploying the
> RFC-final TLS 1.3—previous messages: [1][2]. We share these with the
> community to hopefully avoid other people hitting the same issues.)
> 
> [...]
> 
> However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3
> post-handshake messages are received[5], including KeyUpdate. This
> causes KeyUpdate messages to break with, at least, HAProxy, and with
> NGINX prior to this commit[6]. (There may well be more, but that level
> of breakage was enough to drown any other signal.)
> 
> Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages
> per connection[7]. Therefore clients that send periodic KeyUpdates
> based on elapsed time or transmitted bytes will eventually hit that
> limit, which is fatal to the connection.
> 
> Therefore KeyUpdate messages are not currently viable on the web, at
> least when client initiated.
> 
> [1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE
> [2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ
> [3] https://bugs.openjdk.java.net/browse/JDK-8211806
> [4] https://bugs.openjdk.java.net/browse/JDK-8213202
> [5] https://github.com/openssl/openssl/issues/8069
> [6] 
> https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c
> [7] https://github.com/openssl/openssl/issues/8068
> [8] https://twitter.com/__subodh/status/1085642001595265024

I think we should remediate the reported issues in the 1.1.1b release.
We should probably clear the keyUpdate count when sufficient application
data has been received from the peer.  Where sufficient could be as little
as 1 byte, or could be something more reasonable (say 1MB, allowing for
up to 32 rekeys per MB, which is plenty).

As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
what to do there, but perhaps we could define a new even for keyUpdates
that does not mislead applications into assuming a new "handshake".

-- 
Viktor.

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