Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)

Mike Bishop <> Wed, 08 May 2019 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA92B1201AE for <>; Wed, 8 May 2019 16:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 8VbrUTN5IlgA for <>; Wed, 8 May 2019 16:14:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86FB51201A8 for <>; Wed, 8 May 2019 16:14:02 -0700 (PDT)
Date: Wed, 08 May 2019 16:14:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557357241; bh=RvjpsUkJ/uVrN5OrfzKj/bSfGffXouob+9Tdy3pEbas=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gmvx0lIlXFAH9hEg9X1b9oVgbueLDz6oBn/7ZCe7OmAa+bebpVKpCAOwp5R4+CtW6 p9k0t0ZBiht42kt7j9Q4C9FaE/CzcQGZTG4gaaEhWnN6JtD4+ngMx9bVvFW54hlSM6 T7zoz+OKKRQ4yB0RqOA4prh6WaLfR7pdO04Olhm0=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2673/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd362b9a9971_6f763fa9172cd968165318"; 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: Wed, 08 May 2019 23:14:05 -0000

MikeBishop commented on this pull request.

> +previous handshake messages have not been modified.  Note that the handshake
+does not complete on both endpoints simultaneously, therefore any requirements
+placed on endpoints based on the completion of the handshake are specific to
+the handshake being complete from the perspective of the endpoint in question.
+### Handshake Confirmed {#handshake-confirmed}
+In this document, the TLS handshake is considered confirmed when both of 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 tracking 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 the former, the
+handshake is confirmed.

Also I believe we've been using "greater than" instead of "higher than" when talking about numbers.

> +### Discarding 0-RTT Keys
+Clients SHOULD discard 0-RTT keys as soon as they install 1-RTT keys, since
+they have no use after that moment.
+Clients do not send 0-RTT packets after sending a 1-RTT
+packet ({{using-early-data}}).  Therefore a server MAY discard 0-RTT keys as
+soon as it receives a 1-RTT packet.  However, due to packet reordering, a
+0-RTT packet could arrive after a 1-RTT packet.  Servers MAY temporarily retain
+0-RTT keys to allow decrypting reordered packets without requiring their
+contents to be retransmitted with 1-RTT keys.  Servers MUST discard 0-RTT keys
+within three times the Probe Timeout (PTO, see {{QUIC-RECOVERY}}) after
+receiving a 1-RTT packet.  A server MAY discard 0-RTT keys earlier if it
+determines that it has received all 0-RTT packets, which can be done by
+keeping track of packet numbers.

Maybe be even more explicit and say how?  "...if it has received all packets with packet numbers less than the packet number of the lowest 1-RTT packet received" or something less wordy but similar.

> @@ -1086,25 +1097,44 @@ before the final TLS handshake messages are received.  A client will be unable
 to decrypt 1-RTT packets from the server, whereas a server will be able to
 decrypt 1-RTT packets from the client.
-However, a server MUST NOT process data from incoming 1-RTT protected packets
-before verifying either the client Finished message or - in the case that the
-server has chosen to use a pre-shared key - the pre-shared key binder (see
-Section 4.2.11 of {{!TLS13}}).  Verifying these values provides the server with
-an assurance that the ClientHello has not been modified.  Packets protected with
+Even though 1-RTT keys are available to a server after receiving the first
+handshake messages from a client, it is missing assurances on the state of the
+- The client is not authenticated, unless the server has chosen to use a
+pre-shared key and validated the client's pre-shared key binder; see
+Section 4.2.11 of {{!TLS13}}.
+- The client has not demonstrated liveness.

...unless the server did a Retry.  I'd follow the example of the last bullet and make all of these "might not be authenticated, unless..." and "might not have demonstrated liveness...."

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