Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Watson Ladd <[e-mail]>]

>
> There is no magic involved here.
>
> Apps *know* when to perform reads, and when not to perform reads.
> The middleware doesn't because it is protocol ignorant (it is used
> by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc).
>
> Think of a simple HTTP-based server app receiving a HTTP/1.0 request
> from a TLS-stack on top of a blocking network socket.  If the App would
> keep calling SSL_read() (for an OpenSSL-style API), it would get stuck
> (blocked on read), and at some point the client would give up and
> close the connection (with close_notify or TCP RST), and the server
> waking from either the processing of the close_notify or the TCP RST
> would be unable to deliver a response (which the client would not read
> anyway).

This is an example of the application not knowing which channels are ready.
So no the app doesn't "know when to read".

>
> Whether or not the calling App wants to shutdown a communication
> at different times in both directions depends on the existing semantics
> of that application (which has just added TLS protection around its
> communication).  Reading and processing a close_notify in the TLS stack
> (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude
> any further of sending of responses by the application, so the middleware
> really will want to hold of processing of close_notify alerts unless
> _explicitly_ asked to read further AppData by the application.
>
> With TLS up to TLSv1.2 streaming is no problem, the middleware can
> easily recognize non-AppData records and avoid passing them to
> the TLS stack for processing unless the application explicitly asks
> the middleware to do so.  When TLSv1.3 hides the ContentType,
> the fact that a close_notify was received & processed can only be
> determined after the fact, when the shattered pieces are on the floor.
> Communication in the other direction will be impossible, and it will
> not be possible to prevent this from happening.
>
> While it is conceivable to jump hoops and implement new APIs and
> callback for the TLS stack to allow the middleware instrumenting
> and holding off the processing of TLS close_notify, this is not
> going to allow a drop-in replacement of an existing TLSv1.2 with
> a ContentType-hiding TLSv1.3 implementation underneath an existing
> application.

Yes, you will need to update the middleware component as well. Why is this
a problem?

>
> For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty.
> We were able just fine to drop-in a TLSv1.2 implementation underneath
> apps that were originally built on top of an SSLv3-only stack.
>
>
>
> >
> > Can you explain further why this is a problem: are you expecting that
> > if you send application data to the client after sending the
close_notify
> > itself, the client will consume it?
> >
> > Can you help me understand?
>
> TCP is a full-duplex communication channel and allows shutdown for each
> of the two communication directions performed independently.  There are
> existing communication protocols (other than HTTP) that _use_ independent
> shutdown, and may want to continue using it even after starting to
> protect their original cleatext communication with TLS.
>
>
> If you're vaguely familiar with OpenSSL:
> when SSL_read() has received and processed a TLS record with a
close_notify
> alert, do you know what happens to further calls of SSL_write() of the
same
> handle, which technically is _the_other_ communication direction.

Is this the case? Actually alerts trigger teardown of both sides. There is
no half open state for TLS. Nginx manages fine on OpenSSL.

>
> If you don't know: SSL_write() will fail, because OpenSSL will push out
> a close_notify alert from within SSL_read(), and make the connection
> unusable.  Being able to distinguish AppData records from non-AppData
> records, an application caller of SSL_read() (such as my middleware)
> can prevent loosing the backchannel with no prior warning -- if it
> wants to.  For streaming operation, my middleware DESPERATELY wants to
> prevent the communication channel becoming unusable in both directions
> _before_ the application has received/seen all the app data from the
channel.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls