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

[David Benjamin]

On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

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

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. It's some internal rejiggering of the
record layer. In an alternate universe, the IETF might have specified
KeyUpdate as distinct record type. (It probably should have, given that
KeyUpdate in DTLS and QUIC necessarily look different.)

Skimming the code, it looks like OpenSSL only surfaces
SSL_CB_HANDSHAKE_START because it internally sends post-handshake messages
through the handshake path? This is an implementation detail shouldn't be
visible in the public API. At the public API, one needs to think about what
a given API *means*.

(Does that implementation strategy even work? Handshakes tie up read and
write flows, while the unidirectional post-handshake messages shouldn't. If
you're trying to send a KeyUpdate and the transport blocks, does that block
SSL_read? If I send you half a NewSessionTicket and pause, does that block
SSL_write?)

BoringSSL does not signal SSL_CB_HANDSHAKE_START on KeyUpdate, just
something out the msg_callback. One could imagine dedicated SSL_CB_* hooks
for KeyUpdate if anyone needed it, I suppose, but it's unclear to me if
that's necessary.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190122/2b4673fa/attachment.html>