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

martinduke <> Wed, 16 October 2019 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C15A512007C for <>; Wed, 16 Oct 2019 13:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_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] 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 B6BFnbPeiPXH for <>; Wed, 16 Oct 2019 13:57:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 236B8120122 for <>; Wed, 16 Oct 2019 13:57:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E822661E2B for <>; Wed, 16 Oct 2019 13:57:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571259472; bh=LeAG5JOleLdyCnidBv3PKNQx12eZ32qNMbpq/psYXF0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GJGjqhu/JkQnYBIFZKhLotqjcgzfIE17xGm/KnvnLpjlYmJZgAxwhVXJRgnOItIOw cYMrLlmK9Gvm0avtqdhiRDTN9p2yaKiHLr4qsXYs2RGi/H9vQ8fpCSFfzo18/8Snk5 P/scN7lh4X+IcXXh5MPgR+uzGLycOLwwbcl0E+Ec=
Date: Wed, 16 Oct 2019 13:57:51 -0700
From: martinduke <>
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_5da7844ff3c31_7f093f949a8cd96c596b3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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, 16 Oct 2019 20:57:56 -0000

@marten-seemann has a fairly silly corner case that breaks this:
1) the ack of the CFIN is lost; the server sends no 1-RTT packet.
2) the client acks and sends a PING
3) the server acks it.
4) the client sends ACK + PADDING (which is technically legal). This is sufficient for the server to discard state.
5) The client has not started the 1RTT PTO timer, and we are going to fail the connection.

This is fixable by disallowing ACK+PADDING in response to a non-ack-eliciting packet. At the moment 13.2.1 of quic-transport does not explicitly forbid this. IMO this is an oversight and we should change 13.2.1.

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