Re: [TLS] TLS 1.3, how to close the read side of a connection?

[David Schinazi <[e-mail]>]

Hi Xuelei,

Do you have an example for when you would need to gracefully close the read side?
If you're downloading a 10GB video and the user cancels the download, you can simply tear down the TCP connection by sending a RST.
The benefit of having a graceful read close would be for the server to know that the client application was done, but in the 10GB video example,
I don't see what the server application would do with that information. Do you have an example where the server would treat a graceful read close
differently from a non-graceful close? In TLS 1.2 and prior, the client would send a close_notify, the server would reply with a close_notify
in the middle of the 10GB of application data. That actually doesn't provide any gracefulness to the server application - the point of close_notify
is to indicate that the data you're sending hasn't been truncated, and in this example it does get truncated.

Thanks,
David Schinazi


> On Mar 7, 2018, at 09:51, Eric Rescorla <[e-mail]> wrote:
> 
> Well, this is like TCP in that respect. You send close_notify and then you either stop reading off of or close the TCP socket.
> 
> -Ekr
> 
> 
> On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan <[e-mail] <mailto:[e-mail]>> wrote:
> Hi,
> 
> Per TLS 1.3 draft (Section 6.1, Closure Alerts), the close_notify alert is used to notify the recipient that the sender will not send any more messages on this connection.  And this does not have any effect on its read side of the connection.  I think it means that after sending the close_notify alert, it still can keep reading data from the peer; and after receiving the close_notify alert, it still can keep sending data to the peer.
> 
> The question comes to me is about how to close the read side of the connection.  If closing the read side silently, there are potential issues if the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed.  If sending a close_notify alert, the peer may just treat is as close the its read side and may keep write in its write side.  It does not actually close the read side cleanly.  If keep waiting for the close_notify from the peer, the local may have to wait until the peer happy to close its write side.  It does not sound friendly to the local side.   From example, if I download a 10GB video via TLS 1.3 over VPN, looks like there is no way to indicate the server that I want to cancle in the middle of the downloading in TLS layer.  I may miss something.  I did not find a solution about how to close the read side of TLS 1.3 connections yet.  Please help if you have an idea!
> 
> It's not a problem in TLS 1.2 and prior versions, as the peer MUST respond with a close_notify of its own after receiving a close_notify alert.
> 
> Thanks,
> Xuelei Fan
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls