Re: [quicwg/base-drafts] Clients use the same crypto handshake after Retry (#2746)

Kazuho Oku <> Tue, 11 June 2019 05:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D4B512023C for <>; Mon, 10 Jun 2019 22:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 HuZxUNIYuIgR for <>; Mon, 10 Jun 2019 22:20:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 692F11201D8 for <>; Mon, 10 Jun 2019 22:20:03 -0700 (PDT)
Date: Mon, 10 Jun 2019 22:20:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560230402; bh=8PjCLcrx7fpI6n/xrDsWuJrnnK9V80j1FOxc2kYZ5A4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fZflkAOOrKikd4KBrpfbNbXB/aC2ElWwxYftK8Nsk06xjbcb1BnWPyV/aEnfBDxDT sqHvKuS+gD/m5A3afgnahDfnSoAf5GSsiJ/fqXQOlSvsIgHb+ObVyB1Z6sWs9cgkd9 rZTfTv2OJH6skG021puXI+LovyrV/z0Ub8sHflSY=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2746/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clients use the same crypto handshake after Retry (#2746)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cff3a025f32d_3f9a3fb06eccd964214182"; 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: Tue, 11 Jun 2019 05:20:10 -0000

kazuho commented on this pull request.

LGTM modulo the point below.

 A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT
-packets to the connection ID provided by the server.  A client that sends
-additional 0-RTT packets without constructing a new cryptographic handshake
-message MUST NOT reset the packet number to 0 after a Retry packet; see
+packets to the connection ID provided by the server.  A client MUST NOT change
+the cryptographic handshake message it sends in response to receiving a Retry.
+A client MUST NOT reset the packet number to 0 for any packet number space after

Do we need to stay "to 0"?

I think it'd be better to just omit "to 0", because resetting the packet number does not necessary mean that it goes to zero. It is totally reasonable for an endpoint to start it's packet number from one.

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