Re: [quicwg/base-drafts] Are both types of CONNECTION_CLOSE frames permitted during the handshake? (#3713)

Kazuho Oku <> Tue, 02 June 2020 23:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0250D3A1129 for <>; Tue, 2 Jun 2020 16:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gpa6-eMDbNJ0 for <>; Tue, 2 Jun 2020 16:52:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 564D33A1136 for <>; Tue, 2 Jun 2020 16:52:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EE4E9604C6 for <>; Tue, 2 Jun 2020 16:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591141920; bh=B4n69QIp+nf5Jkg/ArvVk+XZuq6VY51J4w62KP3PPdU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OVIImUOFRMSRRn+qtobc4kBjDN2T+zYVr9w+1f5lufuirNyiwfSWkJ8HiQ3Zux8jh SSqJsIIfPb/PX7wlyWaynp3C1VnoG4p/oYm1q983ag1lrCWkHYJRDfas5KmpYQGNEZ BP+3dpAzx1dzWEzgVL0AyjAfttHkBSud/qyX7glA=
Date: Tue, 02 Jun 2020 16:52:00 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3713/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Are both types of CONNECTION_CLOSE frames permitted during the handshake? (#3713)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed6e6208ffc2_23153f93292cd96c61236"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Tue, 02 Jun 2020 23:52:09 -0000

The question is directly addressed in the TLS specification. It says _CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE frames signaling application errors (type 0x1d) MUST only appear in the application data packet number space._ (

This was the outcome of several issues that we discussed recently, #3440 was the fix that we applied.

I agree that there is ambiguity in the transport draft and that we'd better have an editorial refinement.

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