Re: [quicwg/base-drafts] Which DCID do Handshake retransmissions use? (#3348)

Nick Banks <> Wed, 15 January 2020 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FF74120025 for <>; Wed, 15 Jan 2020 07:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RyKpbNEQr_Vf for <>; Wed, 15 Jan 2020 07:22:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3ABEB12004A for <>; Wed, 15 Jan 2020 07:22:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6065DC61F2A for <>; Wed, 15 Jan 2020 07:22:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579101736; bh=jCqv4S8CB13jqFrx/F23+CggFGhJUVPAmb6N9TzHKjg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dlX3TFgXCHP9NWtwb7kZsbG/lYCI8ElYfFvDxaE3RvMnkkYHDjEd3G8CLV3Rszhzf 8NrzG/CBvYUie7u23AhBTSx8JKE98SAJR81pOq+/PiHexnjFIx+aKpZdXheofNOK3B 6AQxO9K84FS9KG0tuLvLlGhPIBmlNc4QLfqli+L8=
Date: Wed, 15 Jan 2020 07:22:16 -0800
From: Nick Banks <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3348/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Which DCID do Handshake retransmissions use? (#3348)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1f2e2851dda_730d3f80e9acd95c4434"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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: Wed, 15 Jan 2020 15:22:19 -0000

@ianswett that is just indicating when a client should change DCID in response to receiving a Initial/Retry packet with a new CID. I don't think anything restricts either side from sending NEW_CONNECTION_ID frames in their first 1-RTT packets and their peers immediately using them for any packets (including handshake) they send.

Personally, I don't have a problem with (a). I think that no matter what receivers will have to handle the multiple paths but single CID scenario, so I would prefer not to special case the handshake. I also don't think we have handshake confirmation problems because an endpoint should only send a NEW_CONNECTION_ID out when it's able to accept it. Then, if the peer can decrypt the packet with the new CID, I see no reason why it shouldn't be allowed to use it immediately.

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