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

Martin Thomson <> Thu, 13 February 2020 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7752E1200B1 for <>; Wed, 12 Feb 2020 21:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e3tM_ptfQihn for <>; Wed, 12 Feb 2020 21:51:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8232E1200A3 for <>; Wed, 12 Feb 2020 21:51:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC09C8C0E42 for <>; Wed, 12 Feb 2020 21:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581573080; bh=6dY08FPZFvzCNHEDOHJTX+vkr6K/gDhiN5d37B9mTTU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wp4rqJxuu0i8jTNQBSpi1AyItxuauIF1E3QL4h/oQX2IROyF5O2Y1NxIH0+mlX/oH 2oyq4QipWYrmjOSFxqZZYQQaXJi6leY0mzQ6I0A5LFC79FLuqNZd7mXearEVhifYxG xp6brENeiugZRBHQJM/nQIpf1A6Sqmxk+HK/wsZ8=
Date: Wed, 12 Feb 2020 21:51:20 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3446/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e44e3d89cf49_7b6d3f8ad40cd96c180459"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Feb 2020 05:51:25 -0000

That is an entirely reasonable objection.  The question then becomes: what do we do when we have a desire to signal an application-level error, but we aren't sure that the peer can receive a packet that is amply protected?

For instance, if a server accepts 0-RTT only to find that the contents are gibberish, it might signal in a 1-RTT packet with the appropriate application CONNECTION_CLOSE, but it has no guarantee that this will be readable to a client.

I suspect that the right answer is to switch to a transport-level CONNECTION_CLOSE with a different error code in that case.

Allowing application CONNECTION_CLOSE in 0-RTT would still make sense then, if only to keep the API surface consistent.

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