Re: [quicwg/base-drafts] Add Advice and Rules for CONN_CLOSE in Initial and Handshake (#1786)

Kazuho Oku <> Sun, 30 September 2018 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 998E5130DE2 for <>; Sun, 30 Sep 2018 02:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.456
X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 SLXzbOl_mCYI for <>; Sun, 30 Sep 2018 02:24:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61C37130DFA for <>; Sun, 30 Sep 2018 02:24:35 -0700 (PDT)
Date: Sun, 30 Sep 2018 02:24:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1538299474; bh=VUDcud2soHKh3s1XUYjSUM3ymecVSOBRwhsOxkD4/hE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zVP7pxbtg6/iTzkbjBDMoJMriNWVSJPRZPNuKQNnzHat8y1FlbiZywPQbKYvDdyPE T8sS/C37HywW62nXkqUICETPgs4DMB2xPqyO3kWJyTSfxvElO6DvkRWW6yT8a57zC+ b9p0Z44Z08JqEZNxwOrov2+kw23gUmIyNSPUzgow=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1786/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Add Advice and Rules for CONN_CLOSE in Initial and Handshake (#1786)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb096526b722_38f63f9450ad45c0720399"; 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: Sun, 30 Sep 2018 09:24:39 -0000

@martinduke My point is that it is IMO meaningless to have a rule specific to processing  aCONNECTION_CLOSE frame when any other frame (or a malformed payload) can cause the handshake to fail.

OTOH, I am not against clarifying how an endpoint should send CONNECTION_CLOSE during the handshake. In fact, it is essential, because we allow the peer to drop it's keys at it's own discretion. Unless we describe the correct way of sending a CONNECTION_CLOSE frame, the peer might fail to decode the packet that contains CONNECTION_CLOSE.

Having that said, the most straightforward rule for sending CONNECTION_CLOSE would be to send the frame in *all* epochs for which the endpoint possesses the write keys. This is basically the contraposition of the receiver being allowed to drop the read keys at any point.

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