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

ianswett <notifications@github.com> Fri, 25 October 2019 01:49 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32F12006A for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 18:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxggWowtA3ts for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 18:49:08 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DE4120018 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 18:49:08 -0700 (PDT)
Date: Thu, 24 Oct 2019 18:49:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571968147; bh=yQXSFO0i7Gk8JRdWrsf1W+tuRAnOuR/EJn5eF+aBaP8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fBd1IRQrob1tjDs9rADjqhsTWfftUrja5Vbm7KTTk8tDsZeYqRoKg0qA52YjNTId6 F+BkWqCOdk43juBLDzSUEmaWgTBwVZnveV4sj1pfrgvmsPHlAzLUeydzBCRtAYrJ5Q ZlM6ISdvGxNksNgQcMWrPrtcfPtOMc5LdQihycPU=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ2K5H4YRMDADEJO2N3X6KSHEVBNHHB475TUU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3145/review/306928277@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3145@github.com>
References: <quicwg/base-drafts/pull/3145@github.com>
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_5db254936554d_e303f8c460cd96c23162"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/rRR7Qr_2rFvFI918otqK5tbzZI4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 01:49:11 -0000

ianswett commented on this pull request.

Some comments, one to add a backstop in case the server fails to send this in a timely manner.

> @@ -385,13 +385,9 @@ perspective of the endpoint in question.
 
 ### Handshake Confirmed {#handshake-confirmed}
 
-In this document, the TLS handshake is considered confirmed at an endpoint when
-the following two conditions are met: the handshake is complete, and the
-endpoint has received an acknowledgment for a packet sent with 1-RTT keys.
-This second condition can be implemented by recording the lowest packet number
-sent with 1-RTT keys, and the highest value of the Largest Acknowledged field
-in any received 1-RTT ACK frame: once the latter is higher than or equal to the
-former, the handshake is confirmed.
+In this document, the TLS handshake is considered confirmed at the server when
+the handshake completes. At the client, the handshake is considered confirmed
+when the HANDSHAKE_DONE frame is received.

Suggestion: or when an acknowledgement of a 1-RTT packet is received.

I think this provides a stopgap against servers that make stupid or malicious errors.

Also, why aren't you explicitly specifying when the server thinks the handshake is confirmed?

> @@ -760,14 +756,12 @@ 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

I'd vote for SHOULD, because I tend to think dropping them immediately is the best option, but I'm not convinced anything terrible happens if a peer delays dropping them a bit.

> @@ -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 tend to agree with @kazuho point.  How about "The server MUST send HANDSHAKE_DONE with the first outgoing 1-RTT packet or within one round-trip time of handshake completion if no 1-RTT packets are sent."

@kazuho If the server is sending HANDSHAKE_DONE, isn't it no longer 0.5RTT data?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3145#pullrequestreview-306928277