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 E4D5F1270FC for ; Wed, 7 Mar 2018 11:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vimous-com.20150623.gappssmtp.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 jCj4BRWDRv_x for ; Wed, 7 Mar 2018 11:24:02 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015D01200F1 for ; Wed, 7 Mar 2018 11:24:01 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id n136so2122962itg.5 for ; Wed, 07 Mar 2018 11:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimous-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PWyPSZkzUK2LYG20EZrG6odOx/NTaOI9mw7AmPtXix8=; b=OTTek0yMwQxU6wgai7sH6Ktk/vo398TKS5Y1DHS802VqNjn7uZYmlvVyD8JIs+4I35 WM9cpZui3hOi1ZiV2gEJqZ6H9nF4SIwUnsvbEGkCNdfKmeoiuj+pl9ZgTkmCF04oSIqY aW7qA1CDgyTQXA+yVqmFjFBjgEHi0Igk9Ay203TPLRrrQtrbVR5FMRLN2pFvQOi/LoWv xu7cayIydu9ARZQ4efdIR+gL8z4ekvjUtncgMW8fGijEQjQugyiKKIP4ktrs+kEfMIDN m0baY1bJtffaFnwaUeWO3ssziWNjtKKYMMt/vGEIHMwoFkpvC1iFM1A+RzEUy1FqPYEb SVkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PWyPSZkzUK2LYG20EZrG6odOx/NTaOI9mw7AmPtXix8=; b=jShwcMiGqa5JXwiIJH5Vh6wyyzHPiCnijNoV9HWcj5xfWci8N4yIFypmmJcPMx6K+V +YhHZAwi0TKLsX/4CF94ISOW3ABUwGD9OGuyob/akmtUYT0RX3V8zlDf2FTwZdFR7sRD 02R7cveUffVUak6LnGi9KbXB2XUN5pHfGeP9CovM5P1dQHF7nfo+6n1frLX123wYTTlB pzwyPD95gkxJN4QLJnBruRbgcwc7A3KizIGi6E1nMOiqvuP/8M+aRNrXZUQgjptvs46m hVIC+tTGumqtHVypqYo9y+whJhLi9njZsMzATkXFN8Uq4Aul2vTngcUGCkc51vWoyWTQ Cokg== X-Gm-Message-State: AElRT7EZ5EZjobOeKBidWug45iwDdBEvG1+IDrYGGLG7oRUZE0Z7twnk B7UrSZJ2/9sqrRawFu+i882XaDYd72YX+vdRGDOzmQ== X-Google-Smtp-Source: AG47ELsNPIyfIdZRh73pnk8owox/u2OTBTqOnNfoWwWWIodBhhczIKPqw3f+XBbxEYhPA8NtfE7XQBMtxDEUGP4s0vc= X-Received: by 10.36.118.81 with SMTP id z78mr7708983itb.104.1520450641230; Wed, 07 Mar 2018 11:24:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.21.134 with HTTP; Wed, 7 Mar 2018 11:24:00 -0800 (PST) X-Originating-IP: [184.23.214.118] In-Reply-To: <27F60992-04BF-4803-95F4-4F15E4E434FD@apple.com> References: <27F60992-04BF-4803-95F4-4F15E4E434FD@apple.com> From: Xuelei Fan Date: Wed, 7 Mar 2018 11:24:00 -0800 Message-ID: To: David Schinazi Cc: Eric Rescorla , tls@ietf.org Content-Type: multipart/alternative; boundary="001a113f62ba5e93340566d780a9" 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: Wed, 07 Mar 2018 19:24:05 -0000 --001a113f62ba5e93340566d780a9 Content-Type: text/plain; charset="UTF-8" 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 > > > --001a113f62ba5e93340566d780a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

This issue happens when= the TLS connection is established/layered on an existing TCP connection.= =C2=A0 For example:
1. A client connects to a proxy
2. The cl= ient establishes a TLS 1.3 connection to a server via the proxy.
= 3. The=C2=A0 server=C2=A0delivers 2+ records=C2=A0 to t= he client.
4. The client receives the 1st record, and intends to = close the TLS connection

As the=C2=A0 existing TCP connection may be used for follow on= connections, it might not be a solution to close the TCP connection direct= ly.=C2=A0 And=C2=A0the client would better cleanup the data delivere= d by the server.=C2=A0 =C2=A0Otherwise, the data may be used by the next fo= llow on connection and may cause unknown issues.

Then the question= comes to me: how does the client close the TLS connection?=C2=A0Clo= sing the TCP connection may be not desired as it does not really have a TCP= connection to the server.=C2=A0 It would be nice to close the TLS connecti= on but keeping the TCP connection alive.

Looks lik= e there is no way to close the read side of a TLS connection in TLS layer p= er the current TLS 1.3 specification.=C2=A0 The close_notify is used to ind= icate the closure of client write side, but not the server write side.=C2= =A0 If the client sends the close_notify for read side closure, after recei= ving the close_notify the server side will not receive data, but may still = send data.=C2=A0 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=C2=A0 close_notify alert and then wait for the server= =C2=A0close_notify alert, and all of the intermed= iate data is discarded.=C2=A0 There are still some problems, but in theory = the client can cleanup the TCP channel.

In the TLS 1= .3 specification, it says:
=C2= =A0 =C2=A0 
   If the application pro=
tocol 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" a=
lert
   before indicating end-of-data to the application-layer.

For client read side in above case, it means that the serv= er side MUST deliver a close_notify.=C2=A0 But it does not say if a client= =C2=A0initiates the TLS closure, how could the client indicates the server = for a close_notify alert.

Thanks for the suggestion of TCP = RST option.=C2=A0 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 sim= ply 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 clie= nt application was done, but in the 10GB video example,
I don'= ;t see what the server application would do with that information. Do you h= ave 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 wo= uld 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_no= tify
is to indicate that the data you're sending hasn't b= een truncated, and in this example it does get truncated.

Thanks,
David Schinazi
<= br>

On Mar 7, 2018, at 09:51, Eric R= escorla <ekr@rtfm.com<= /a>> wrote:

Well, this is like TCP in that respect. You se= nd close_notify and then you either stop reading off of or close the TCP so= cket.

-Ekr


On Wed, Mar 7, 2018 at 9:40 AM, Xuel= ei Fan <xuelei.fan@vimous.com> wrote:
Hi,

Per TLS 1.3 dr= aft (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 conn= ection.=C2=A0 And this does not have any effect on its read side of the con= nection.=C2=A0 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 th= e connection.=C2=A0 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.= =C2=A0 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.=C2=A0 It does not = actually close the read side cleanly.=C2=A0 If keep waiting for the close_n= otify from the peer, the local may have to wait until the peer happy to clo= se its write side.=C2=A0 It does not sound friendly to the local side.=C2= =A0 =C2=A0From example, if I download a 10GB video via TLS 1.3 over VPN, lo= oks like there is no way to indicate the server that I want to cancle in th= e middle of the downloading in TLS layer.=C2=A0 I may miss something.=C2=A0= I did not find a solution about how to close the read side of TLS 1.3 conn= ections yet.=C2=A0 Please help if you have an idea!

It's not a problem in TLS 1.2 and prior versions, as the peer MUST re= spond with a close_notify of its own after receiving a close_notify alert.<= /div>

Thanks,
Xuelei Fan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing listTLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tls

--001a113f62ba5e93340566d780a9--