Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15F12762F for ; Thu, 8 Mar 2018 09:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heFcXpmSbRFG for ; Thu, 8 Mar 2018 09:48:01 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B3E127522 for ; Thu, 8 Mar 2018 09:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1520531281; x=2384444881; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wkfot0DcpMblKbfclGzXhFLXv/gV22rU4jvYW/Jbbcg=; b=Th7UW8W7XMI7oFtmnyRo+W5eOAzQTz/HZtfLeQtxoP1O5/vpuhlOwVougWrly4rG K/s0ZNv2CHpibvGWaJvcPwOrqr/ORlRZJYZz6WCRR6QdgmwYa5gFO0psn8m8BYgt J1WpEs4ez+yvyWM1LsD2AaBEa2vwabY85FhIIwURcH8VBzMTi7pjVQn91nQZwXaI hdzjbv2lK1egWBLZraRSwBsCerpfiP1kq6bFWi2xpGvWgrBeb07aX3v58aALvQv/ R3z/RNvvRo+if+FUqNiNUbIzY04d5afyc/t1e/szYUJuLvzS60R5qdRu97satcwf eDIp/bSfFaQJAUvl/Blyaw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id DB.32.28259.15771AA5; Thu, 8 Mar 2018 09:48:01 -0800 (PST) X-AuditID: 11973e15-f06549e000006e63-6e-5aa17751deb9 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id DE.A8.23499.05771AA5; Thu, 8 Mar 2018 09:48:01 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lEWlWzBPglqKsBTXuT2HtA)" Received: from [17.234.21.111] (unknown [17.234.21.111]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P5A007NJ9FXDC60@nwk-mmpp-sz11.apple.com>; Thu, 08 Mar 2018 09:48:00 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Thu, 08 Mar 2018 09:47:56 -0800 In-reply-to: <140080C241BAA1419B58F093108F9EDC1678CB3C@UK-MAL-MBOX-02.dyson.global.corp> Cc: "tls@ietf.org" , Xuelei Fan To: Tony Putman References: <27F60992-04BF-4803-95F4-4F15E4E434FD@apple.com> <09BF7A66-E847-4C2B-98FF-EBF3B0DF97C1@apple.com> <140080C241BAA1419B58F093108F9EDC1678CB3C@UK-MAL-MBOX-02.dyson.global.corp> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FAYoRtYvjDK4MY+DotP57sYLbZvvMti cf/YWnYHZo9DP38yeSxZAiSe7j3AGMAcxWWTkpqTWZZapG+XwJVx58c/toJv95gqZm3/ztbA uG0dUxcjJ4eEgInE1WM9bCC2kMBqJont//xh4jMvv2bpYuQCih9ilGiYdY8RJMErICjxY/I9 FhCbWSBM4tnf6SwQzROZJO5M1QSxhQWkJbou3GXtYuTgYBPQkjiwxgii1Ubi8fqDjBAl7hJL L90B28sioCrxa9MvZhCbUyBKYuLUX6wQ410lpsx8DFYjIqAucffiCiaIVbeZJW7f84W4U0li +vfbbBD2GjaJ1RdYJzAKzUJy6Swkl0LYWhLfH7UC2RxAtrzEwfOyEGFNiWf3PrFD2NoST95d YF3AyLaKUSg3MTNHNzPPTC+xoCAnVS85P3cTIyg6ptuJ7mA8s8rqEKMAB6MSD6+Fy8IoIdbE suLK3EOM0hwsSuK8laULooQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwej/aIvot9O2b+Kzp GrkRZu8f3C3YxlRam7RQLt9kSUdh4o7CRbpGX6+pWNTY+h0IY/azW/d/om+i2Q99//z2zUw7 +R7Y5N6aXC/P07z7KsMuy56sOZOCD3BpTSxxT9M3af/YEHhGtOFFgH6SH6tC9U+Bc2Ladzc7 MDMHfNo6qUL97Ayl9hwlluKMREMt5qLiRACxwKqlbwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FA8WzewfGGUwc0/zBafzncxWmzfeJfF 4v6xtewOzB6Hfv5k8liyBEg83XuAMYA5issmJTUnsyy1SN8ugSvjzo9/bAXf7jFVzNr+na2B cds6pi5GTg4JAROJmZdfs3QxcnEICRxilGiYdY8RJMErICjxY/I9FhCbWSBM4tnf6WC2kMBE Jok7UzVBbGEBaYmuC3dZuxg5ONgEtCQOrDGCaLWReLz+ICNEibvE0kt32EBsFgFViV+bfjGD 2JwCURITp/5ihRjvKjFl5mOwGhEBdYm7F1cwQay6zSxx+54vxJ1KEtO/32abwMg/C8l1s5Bc B2FrSXx/1ApkcwDZ8hIHz8tChDUlnt37xA5ha0s8eXeBdQEj2ypGgaLUnMRKU73EgoKcVL3k /NxNjOCALozYwfh/mdUhRgEORiUe3geOC6OEWBPLiitzgUHEwawkwtubDRTiTUmsrEotyo8v Ks1JLT7EKM3BoiTO2/JzZpSQQHpiSWp2ampBahFMlomDU6qBka8u2yjh4c6Pn6qnVq4LKjt1 Rl5+4oLklC9NOjqLp+n6eL/yFGWxmb9j9iW7iHL3h8/2GBx372+/bZn9N7FrzZrkkGUrvX4l qL/abGLVaNp/9/2FZaEGXbXWkww6LZmbrF5Jc7TtUUg5G5LIkBVcvOpaGtONE/s3ltyWnu0z p797R9yfk7WdSizFGYmGWsxFxYkAvshN0WQCAAA= Archived-At: Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 17:48:04 -0000 --Boundary_(ID_lEWlWzBPglqKsBTXuT2HtA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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 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 ) 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-bounces@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 > 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 > 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 > 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 > 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 > 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 > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > 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. --Boundary_(ID_lEWlWzBPglqKsBTXuT2HtA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable 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.Putman@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= ) 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-bounces@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 = <dschinazi@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.fan@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 = <dschinazi@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 <ekr@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.fan@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.  =  =46rom 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
https://www.ietf.org/mailman/listinfo/tls

 
_______________________________________________
TLS mailing list
TLS@ietf.org
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.

= --Boundary_(ID_lEWlWzBPglqKsBTXuT2HtA)--