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...@rtfm.com> 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 <xuelei....@vimous.com > <mailto:xuelei....@vimous.com>> 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 > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
