Re: [quicwg/base-drafts] Fixed handshake key deadlock issue (#3093)

Martin Thomson <> Tue, 22 October 2019 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21F5B120A83 for <>; Mon, 21 Oct 2019 17:20:19 -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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u5EaRuwLNjAa for <>; Mon, 21 Oct 2019 17:20:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6190D120026 for <>; Mon, 21 Oct 2019 17:20:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B43C52C33CD for <>; Mon, 21 Oct 2019 17:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571703616; bh=djVhZzFB+PIdoMm9zOgPrwhEOFbHU9CUKI4HysfKHus=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tq9SEbt8SWDto0ylTn7n1Fk3M1xWZoqD2FtuXSguHW8Adjj7ZnOsIY0TZC1DZIeNH OVw1xMPFsfVY8ywVzqll7YIyLHhsc1IRCtRiATZyjKy5M8csfrKsJdwiE/++/gBdoy qbhXcMG7Rp4XHmxdjDLt75vZLXo2msvAb7mQOIEU=
Date: Mon, 21 Oct 2019 17:20:16 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3093/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Fixed handshake key deadlock issue (#3093)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dae4b40a5b5f_48313f8c75acd96079657"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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, 22 Oct 2019 00:20:19 -0000

As we concluded at the meeting, we're going to keep Handshake keys indefinitely.

FWIW, I don't believe that it is possible to find a confirmation step that doesn't involve both peers actively driving the state machine.  Otherwise, peers might not reach the same state within a reasonable time.  This change still has problems (more below) and only adds delay to the confirmed state by making the requirements more complex.

Here's an example of how this fix breaks.  I'm sure that there are more:


<details><summary>web sequence diagram code</summary>
title Bad scenario

Client->Server: Initial
Client->Server: 0-RTT (ack-eliciting)
Server->Client: Initial + Handshake
Server->Client: 1-RTT (ACK for 0-RTT)

Client->Server: Handshake
Server-->Client: ACK (lost)

Client->Server: 1-RTT (ack-eliciting + ACK for 0.5-RTT)
Server->Client: 1-RTT (ACK for 1-RTT)
note right of Server
   The server now believes that 
   the handshake is confirmed
end note

note left of Client
   The client isn't confirmed
end note

note over Client,Server
   Considerable time can now elapse
end note

Client->Server: Handshake (retransmission)
note over Server: drop garbage
Client->Server: Handshake (retransmission)
note over Server: drop garbage ...

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