Hi Tony, I agree with you, TLS should not have requirements on the underlying transport. If there is a use case that would require endpoints have a way to signal to the peer that they're done reading, I would suggest writing a draft about a new close_request alert. I personally don't think this needs to be in the main TLS 1.3 spec, though.
Thanks, David > On Mar 8, 2018, at 02:23, Tony Putman <tony.put...@dyson.com> wrote: > > David, > > I think this is a valid concern. It's been commented on > (https://www.ietf.org/mail-archive/web/tls/current/msg25579.html > <https://www.ietf.org/mail-archive/web/tls/current/msg25579.html>) that the > draft has NO requirements on the underlying transport. There are potentially > other transports for TLS (such as being worked by the ATLAS WG) which may not > have a way to terminate the transport. > > At a minimum this must be addressed in DTLS, but it seems to me that the > addition of a close_request alert is a small matter which would benefit both > protocols. Of course, this could be added at a later date if/when the need > arises. > > Regards, > Tony > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xuelei Fan > Sent: 07 March 2018 20:54 > To: David Schinazi > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection? > > Hi David, > > The case I can think of now is the START TLS protocols (Opportunistic TLS). > But looks like these protocols need to use an existing plain-text socket, and > then establish a TLS connection over it, and will never go back to plain-text > again. Maybe, for START TLS protocols, closing TLS connection just implies > close the underlying TCP socket in practice. We don't do that previously as > we don't know how the plain-text socket can be used in practice in the > follow on processes after TLS get closed (while socket still alive). If an > application gets indication that the TLS connection get closed, it can use > the cleanup socket. So it does not actually need to understand the TLS > specifics. > > I'm a little bit hesitate if there is a reality user case for such > requirement. Maybe, I can just close the socket, and see what the > compatibility impact could be. > > Thanks, > Xuelei > > On Wed, Mar 7, 2018 at 12:21 PM, David Schinazi <dschin...@apple.com > <mailto:dschin...@apple.com>> wrote: > Hi Xuelei, > > Can you elaborate on what proxy protocol you're using that can reuse the TCP > connection for follow on connections, and what semantics it has? > As far as I know, SOCKS and HTTP CONNECT don't support this. > Additionally, the close_notify alerts are sent encrypted so the proxy > wouldn't be able to tell that applications are done with TLS. > > Thanks, > David > > > > On Mar 7, 2018, at 11:24, Xuelei Fan <xuelei....@vimous.com > <mailto:xuelei....@vimous.com>> wrote: > > Hi David, > > This issue happens when the TLS connection is established/layered on an > existing TCP connection. For example: > 1. A client connects to a proxy > 2. The client establishes a TLS 1.3 connection to a server via the proxy. > 3. The server delivers 2+ records to the client. > 4. The client receives the 1st record, and intends to close the TLS connection > > As the existing TCP connection may be used for follow on connections, it > might not be a solution to close the TCP connection directly. And the client > would better cleanup the data delivered by the server. Otherwise, the data > may be used by the next follow on connection and may cause unknown issues. > > Then the question comes to me: how does the client close the TLS connection? > Closing the TCP connection may be not desired as it does not really have a > TCP connection to the server. It would be nice to close the TLS connection > but keeping the TCP connection alive. > > Looks like there is no way to close the read side of a TLS connection in TLS > layer per the current TLS 1.3 specification. The close_notify is used to > indicate the closure of client write side, but not the server write side. If > the client sends the close_notify for read side closure, after receiving the > close_notify the server side will not receive data, but may still send data. > Even if the server side stop sending data, the client side does not actually > know how may data has been delivered by the server, and how to clean up the > TLS channel. > > For such cases in TLS 1.2, the client can send a close_notify alert and then > wait for the server close_notify alert, and all of the intermediate data is > discarded. There are still some problems, but in theory the client can > cleanup the TCP channel. > > In the TLS 1.3 specification, it says: > > If the application protocol using TLS provides that any data may be > carried over the underlying transport after the TLS connection is > closed, the TLS implementation MUST receive a "close_notify" alert > before indicating end-of-data to the application-layer. > > For client read side in above case, it means that the server side MUST > deliver a close_notify. But it does not say if a client initiates the TLS > closure, how could the client indicates the server for a close_notify alert. > > Thanks for the suggestion of TCP RST option. I will evaluate if TCP options > can help. > > Thanks & Regards, > Xuelei Fan > > > On Wed, Mar 7, 2018 at 10:19 AM, David Schinazi <dschin...@apple.com > <mailto:dschin...@apple.com>> wrote: > 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 > <mailto: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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > > > > > > Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, > SN16 0RP, UK. > This message is intended solely for the addressee and may contain > confidential information. If you have received this message in error, please > immediately and permanently delete it, and do not use, copy or disclose the > information contained in this message or in any attachment. > Dyson may monitor email traffic data and content for security & training.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
