MIME-Version: 1.0
In-Reply-To: <CAJR_8q+LmWLk92dEq6ZQ0+jsanWJLbptB4RwdmkhNncSLZs6wA@mail.gmail.com>
References: <CAJR_8q+LmWLk92dEq6ZQ0+jsanWJLbptB4RwdmkhNncSLZs6wA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 7 Mar 2018 09:51:32 -0800
Message-ID: <CABcZeBM-XM4XeeKuAjpBizDOxOvqN92-QRp5-T371xkTi6BmgA@mail.gmail.com>
To: Xuelei Fan <xuelei.fan@vimous.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114992e01060530566d63838"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TfhD6_ghKh-c5hsVmqRYobseOMQ>
Subject: Re: [TLS] TLS 1.3, how to close the read side of a connection?
Precedence: list

--001a114992e01060530566d63838
Content-Type: text/plain; charset="UTF-8"

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.   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
>
>

--001a114992e01060530566d63838
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, this is like TCP in that respect. You send close_not=
ify and then you either stop reading off of or close the TCP socket.<div><b=
r></div><div>-Ekr</div><div><br></div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Wed, Mar 7, 2018 at 9:40 AM, Xuelei Fan <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:xuelei.fan@vimous.com" target=3D"_blank"=
>xuelei.fan@vimous.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">Hi,<div><br></div><div><div>Per TLS 1.3 draft (Section=
 6.1, Closure Alerts), the close_notify alert is used to notify the recipie=
nt that the sender will not send any more messages on this connection.=C2=
=A0 And this does not have any effect on its read side of the connection.=
=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.</div><div><br></div><div=
>The question comes to me is about how to close the read side of the connec=
tion.=C2=A0 If closing the read side silently, there are potential issues i=
f 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 r=
ead side and may keep write in its write side.=C2=A0 It does not actually c=
lose the read side cleanly.=C2=A0 If keep waiting for the close_notify from=
 the peer, the local may have to wait until the peer happy to close its wri=
te side.=C2=A0 It does not sound friendly to the local side.=C2=A0 =C2=A0Fr=
om example, if I download a 10GB video via TLS 1.3 over VPN, looks like the=
re is no way to indicate the server that I want to cancle in the middle of =
the downloading in TLS layer.=C2=A0 I may miss something.=C2=A0 I did not f=
ind a solution about how to close the read side of TLS 1.3 connections yet.=
=C2=A0 Please help if you have an idea!</div><div><br></div><div>It&#39;s n=
ot 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.</div></div><=
div><br></div><div>Thanks,</div><div>Xuelei Fan</div></div>
<br>______________________________<wbr>_________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/tls</a><br>
<br></blockquote></div><br></div>

--001a114992e01060530566d63838--