[TLS] TLS 1.3, how to close the read side of a connection?

Xuelei Fan <xuelei.fan@vimous.com> Wed, 07 March 2018 17:40 UTC

Return-Path: <xuelei.fan@vimous.com>
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 33DCE1274D2 for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 09:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 L4TTNXlrY7dG for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 09:40:13 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 8038C1200C1 for <tls@ietf.org>; Wed, 7 Mar 2018 09:40:13 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id m22so3907101iob.12 for <tls@ietf.org>; Wed, 07 Mar 2018 09:40:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimous-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KgMLCGwOeW7R4cSrWvlSagHTf/7Ukg72dOtIo5gRDKg=; b=wI5o4BQ/ghF1cahfjAtMCIK+kM98vXpKbmSI2vHt5LqQZlbsejOcGiox7CXHqnRQyb Pw/1uKDq6EWgOXA63RqlSxad141hBtyrmhekmS4BXntgykmYaGxLyXRWwpILvt3yVYYX uJeX6WQLT6IytoejKkKlGRbTvRveD3jzUL6xH5wqisLPnXasU5NgGAENtXY24Ts0iByJ t8PySPNN8ylISEnRkN1wLjhyvk/CH3O5ahGaF+Sa67iqTW1fSLF4oFIYJtXYdUcHNV+Q WI5VdSM+HJKjRDH7ioJ6LgKYCgAlrYtAaX7wtep6GuC4ANZ3uP4j0OHL8RJwnkPaeUdk BNqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KgMLCGwOeW7R4cSrWvlSagHTf/7Ukg72dOtIo5gRDKg=; b=oC/X6gTSBiockhwl0uZjGqTTRyURBeFiFrimCWmpdMOtRvHv5vfam1H0IeRrRDJH5Y XWDm6tNwRqo9kdBNgWz4EP7NYOBTd4VtPhPj7nzHOQYS4uAQJ9jGZD9qBA4y7S2ZzIAE hZqgTDri5GL1D5a6hsCXP5bTSY3OTXuzM/sXpiRSAd6itgHyQ/rfhg8aGk77pGPrX1jO 77p/z3xi7Gb8j9LPhNDsdVOT8xPj4quGN7Isy/Y+z2i/JRQZkNjEnhUSvBtKp0wYgiqk UwDMpCd4cPNTb8++jgVM7DzoNWYF3TVBLI+Bl7X2Uno4wX9XMbZxSCvsOP0DHF9EOqAR /w2g==
X-Gm-Message-State: APf1xPBR6dOhzEL4fOSHrM14q1p19qRLYSzbKcUXKprqzC28PjhVS6yG E8JNUSctJ9ueAvFbWS7SvzaFYPU3J0PgsyNOJaJET/upIy8=
X-Google-Smtp-Source: AG47ELv4Jr8lhYx3fRdT8LjBPn4j3BQRF186qMWk6KgNfoy6HPSey03j9DVzLf8vCTRzB3OFI6MoZV32n0QwKWfheAs=
X-Received: by 10.107.89.13 with SMTP id n13mr27365035iob.154.1520444412678; Wed, 07 Mar 2018 09:40:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.21.134 with HTTP; Wed, 7 Mar 2018 09:40:12 -0800 (PST)
X-Originating-IP: [184.23.214.118]
From: Xuelei Fan <xuelei.fan@vimous.com>
Date: Wed, 07 Mar 2018 09:40:12 -0800
Message-ID: <CAJR_8q+LmWLk92dEq6ZQ0+jsanWJLbptB4RwdmkhNncSLZs6wA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="f4f5e803dce41e6e9d0566d60d9c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Pp8TGgZyvoJJy6RjecWXW9AJRqU>
Subject: [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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2018 17:42:17 -0000

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