Re: [quicwg/base-drafts] CONNECTION_CLOSE in Handshake too (#3293)

Martin Thomson <notifications@github.com> Wed, 11 December 2019 01:17 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA66120086 for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 17:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeMghhLWio5x for <quic-issues@ietfa.amsl.com>; Tue, 10 Dec 2019 17:17:33 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09152120059 for <quic-issues@ietf.org>; Tue, 10 Dec 2019 17:17:33 -0800 (PST)
Date: Tue, 10 Dec 2019 17:17:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576027052; bh=ldqgmlVbQDz4lmkm2QEf1vY1ftKSPBoS9OK1sG0RdCo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Hp4Msns+GEu+Nvl0D8DGOiap+E8Rq5JHaTMiJJPaP3rrqE9dXXyYj6TyZAnmIaehR hBTINIpSoznUrvC+hzWFjwowBoKsxHlzyGccWFOlGCYKfJZVs5nDcDA7qykzsBuo0T vRgVflxUpRw72Gw6YQsx0q5T7OqMYoKkA2p1yQ+E=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3QYTGOV2SESBPFRBF37V3CZEVBNHHB72M6BM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3293/review/330248580@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3293@github.com>
References: <quicwg/base-drafts/pull/3293@github.com>
Subject: Re: [quicwg/base-drafts] CONNECTION_CLOSE in Handshake too (#3293)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df043ac24bbb_292c3fa22c6cd960953a9"; 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/SPFpnKs3KqjXJTqSseNIvblUuD4>
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: Wed, 11 Dec 2019 01:17:34 -0000

martinthomson commented on this pull request.



> @@ -2481,12 +2481,15 @@ have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a
 Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send
 CONNECTION_CLOSE frames in an Initial packet.
 
-A client will always know whether the server has Handshake keys
-(see {{discard-initial}}), but it is possible that a server does not know
-whether the client has Handshake keys.  Under these circumstances, a server
-SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
-to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+A client will always know whether the server has Handshake keys (see
+{{discard-initial}}), but it is possible that a server does not know whether the
+client has Handshake keys.  Under these circumstances, a server SHOULD send a
+CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at
+least one of them is processable by the client.  Similarly, a peer might be

To ensure that there is a record of this.  There are situations where handshake keys are available for sending, but not receiving at both peers.

The client might have sent it's last Handshake packet, but the server can't read 1-RTT until it processes that packet (and maybe verifies a certificate).  A server might have sent its first Handshake flight, but the client hasn't received all of it, so it won't have 1-RTT keys.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3293#discussion_r356361750