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

Kazuho Oku <> Mon, 01 October 2018 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB85B12F1AC for <>; Sun, 30 Sep 2018 18:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Status: No, score=-8.455 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, 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 XlKiVAuABjkz for <>; Sun, 30 Sep 2018 18:02:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0BB91294D7 for <>; Sun, 30 Sep 2018 18:02:29 -0700 (PDT)
Date: Sun, 30 Sep 2018 18:02:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1538355748; bh=lu7S+4ODLZGXqTDVQKCwPrNwXV0xciwzDz1p376NDo8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qhK0RAd7K9qzK+eRGe+McR329Hed8h+wKhFoJmUoVt/Ebj8J4JzCnDnMXyODvTSHN dtshhzjQDeL6++cJ8fShCANeO1D+mmdxZZsuOXcOMB93ZZL2R1FazexCJz+Vy10PCO yi7SARQfK4tnrckj8V4VYsjAwePo9vp94rkGKIc8=
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_5bb17224c75eb_4d23fc54ded45c0240e7"; 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: Mon, 01 Oct 2018 01:02:32 -0000

> I'm not sure all epochs are necessary. Possibly "in the highest epoch the sender knows the peer can process and one higher if the peer may be able to process it." or something along those lines?

Yeah. The problem here is that the rule to determine "the highest epoch the peer can process" is complex and specific to TLS 1.3. IIRC that is one of the reasons we favored the explicit-ACK approach instead of the implicit- approach.

Anyways, the requirement here is that we need to at least state that the endpoints MUST send CONNECTION_CLOSE protected by a key that the peers established, if such key is available. Otherwise, peers trying to do their best against Initial packet injection attacks would not recognize the frame.

Perhaps stating something like the following might suffice; that for sending CONNECTION_CLOSE during handshake, an endpoint
* uses the Initial packet if it does not know the Handshake write key
* uses the Handshake packet if it has received a Handshake packet
* uses both the Initial packet and the Handshake packet if it has not received a Handshake packet but it knows the Handshake write key

The downside of the rule will be that the peers might not be able to drop Handshake keys as aggressively as the Initial keys. But IIUC that's fine from security perspective because Handshake packets are protected by the key agreement.

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