Re: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)

Kazuho Oku <> Fri, 25 October 2019 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E105112008D for <>; Thu, 24 Oct 2019 18:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 1U0AGYv7waI0 for <>; Thu, 24 Oct 2019 18:25:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEEF2120018 for <>; Thu, 24 Oct 2019 18:25:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 43C65C60216 for <>; Thu, 24 Oct 2019 18:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571966721; bh=i/bUU9nduMS7XQfUUoDWKX2bsmqnHP2gyRbfOPxK9ko=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ilfaFHyAU2D3sj9dYlxz8Xa9nh6m9CKsBps0YNxOrm+swNsB23mSkhJX3DxBdkIRJ AA29M21PPdwMxnTE5IYi0mN/t0REiPmCsFGTsisvaTOUVr8HYYuTlVO+29If62dwzA vEPZlbVxdnG0T0yf6iAbM0FjzAIPo5f7lWldQmrU=
Date: Thu, 24 Oct 2019 18:25:21 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3145/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db24f0134587_79f33fd1774cd9606897b"; 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: Fri, 25 Oct 2019 01:25:24 -0000

kazuho commented on this pull request.

> @@ -760,14 +756,9 @@ and ignoring any outstanding Initial packets.
 ### Discarding Handshake Keys
-An endpoint MUST NOT discard its handshake keys until the TLS handshake is
-confirmed ({{handshake-confirmed}}).  An endpoint SHOULD discard its handshake
-keys as soon as it has confirmed the handshake.  Most application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to discard their handshake keys promptly.  Endpoints that do
-not have reason to send immediately after completing the handshake MAY send
-ack-eliciting frames, such as PING, which will cause the handshake to be
-confirmed when they are acknowledged.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed
+({{handshake-confirmed}}).  The server MUST send a HANDSHAKE_DONE frame within
+one round-trip time of handshake completion.

I think "within one round-trip time" is too long. As this happens before both endpoints have good estimation of RTT, it could well be the case that the server's estimated RTT be much greater than the PTO of the client. In such case, it would seem to the client as if the CF had been lost.

I think we should say "SHOULD immediately send", with possibly acknowledging the fact that the server "can bundle the HANDSHAKE_DONE frame with 0.5 RTT data."

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