[quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)

Martin Thomson <notifications@github.com> Mon, 10 February 2020 08:31 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C67B912009E for <quic-issues@ietfa.amsl.com>; Mon, 10 Feb 2020 00:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zGyn-LdBcR34 for <quic-issues@ietfa.amsl.com>; Mon, 10 Feb 2020 00:31:41 -0800 (PST)
Received: from out-27.smtp.github.com (out-27.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57D212008C for <quic-issues@ietf.org>; Mon, 10 Feb 2020 00:31:41 -0800 (PST)
Date: Mon, 10 Feb 2020 00:31:40 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581323500; bh=kmDg9NXfPDXlrzSwOKKA5DaH5NW7MGltwLgs2ooHtdA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Os6NBKNmTlKzTgwqrOY2D2lzzHr1gX2yXmO1KMfrzciAf0eBWyK8dYS3nOxdgXIDu uQoRSZeCEV4qMGHVQeqqEEbDR+Ji6tj80O+yuCS+6w+rSXloWid25p/dwl4ky7Dvsy KxIlUHE+jkIn+kiEPqMhyx7yH0+DHoZhrcM3ZLhA=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3WONZUU5B5IHZEZ4N4JZDWZEVBNHHCDBMSUQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3446@github.com>
Subject: [quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4114ece3622_4fe13f88750cd9643131a7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/8Spj_b3uNJ_jExkxEpncytyx_Rc>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 08:31:44 -0000

In fixing #3435, I realized that it was tricky to send an application-level close in 0-RTT because of the need to potentially send a close in Initial or Handshake packets. However, the same applies to 0.5-RTT. The client might not have 1-RTT keys when the server sends a CONNECTION_CLOSE in a short header packet.

Rather than try to remap application errors onto transport errors to solve this, just let the application signal an error any time.  Sure, both 0-RTT and 0.5-RTT both have in common the lack of input from a peer, so signaling an error seems unnecessary, but the restriction we have only exists because we aren't sure that the condition is valid. But it might be. Imagine that an application error condition could be triggered by TLS extensions or transport parameters. Or maybe the endpoint just doesn't want to continue.

Lifting the restriction should simplify a lot of things.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: