Re: [quicwg/base-drafts] Discard Initial keys as soon as possible (#2045)

Mike Bishop <> Thu, 29 November 2018 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 184A9130E1D for <>; Thu, 29 Nov 2018 08:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 fN2CqJaH53g6 for <>; Thu, 29 Nov 2018 08:49:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65252130E85 for <>; Thu, 29 Nov 2018 08:49:15 -0800 (PST)
Date: Thu, 29 Nov 2018 08:49:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1543510154; bh=Rqbn+HG3dasdj+krGeeigPdFfdOOayhLZOw4WUnKsc0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fp7LOC2/0L7UWAlUUOgOsIDvZ0OK5JBDaiVitXZUZ879zkmG5qLCxzy5VwuHqF7l4 dlGkhv6BQUlhntFK3ZquRo2LF6UbOPzFde9bRfIIBua1CquAimks9YXa7kEXN7wU/h UTrbTf7xURyDbTAhZHOexlq9krccSC6TprSqyrCA=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2045/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Discard Initial keys as soon as possible (#2045)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c00188a45f10_30bb3fc69f4d45b81812d5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 29 Nov 2018 16:49:25 -0000

MikeBishop commented on this pull request.

> @@ -3592,6 +3594,21 @@ and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
 frame sent in the first Initial packet.  Cryptographic handshake messages
 subsequent to the first do not need to fit within a single UDP datagram.
+### Abandoning Initial Packets {#discard-initial}
+A client stops both sending and accepting Initial packets when it sends its
+first Handshake packet.  A server stops sending and accepting Initial packets
+when it receives its first Handshake packet.  Though packets might still be in
+flight or awaiting acknowledgment, no further Initial packets need to be
+exchanged beyond this point.  Initial packet protection keys are discarded (see
+Section 4.10 of {{QUIC-TLS}}) along with any loss recovery and congestion
+control state (see Sections and 6.9 of {{QUIC-RECOVERY}}).

Okay, I see that reading of the -recovery text.  But that's really weird -- we *do* know that these packets have arrived, so why define a special operation for "forgetting" packets rather than just marking them arrived as normal and be done?

If one component were trying to game the other -- for example, by sending many Initial packets with redundant data -- then you wouldn't want to let the packetizer force many packets to be "acknowledged" when only one actually needed to get through to produce the effect.  But the ways to game that I see offhand are intra-implementation, and I think we can say that's not an attack of concern.

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