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

[Viktor Dukhovni]

> On Jan 22, 2019, at 2:06 PM, Adam Langley <agl at imperialviolet.org> 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.