Re: [quicwg/base-drafts] It is unclear if some frames are forbidden in 0-RTT (#3430)

Mike Bishop <> Thu, 06 February 2020 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CC98120273 for <>; Thu, 6 Feb 2020 02:45:14 -0800 (PST)
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 FgYlhENOlMZH for <>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C81F5120271 for <>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1CA936A0D01 for <>; Thu, 6 Feb 2020 02:45:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1580985911; bh=SPzRpNjxKtrjNBYWhDObYWThOZ5eOJOgcDGstWEKDZU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oqhOt2j3Vsw3+zRmJ3vV43hTJR/1zM8bVNnQS8OzPfHzBVwqZt0/BoKw4FzBsKyfU lDymYJPFCs45XfW7elAQmpw3OEvxYGm0WBzBji82C3xnZ4rlju2mN3SZmadIH3V6+5 qA1tqIXY0DBvoJvp3MIe+DF48l1pLCROatIrUv1E=
Date: Thu, 06 Feb 2020 02:45:11 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3430/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] It is unclear if some frames are forbidden in 0-RTT (#3430)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e3bee37e78a_16073f998decd964139692"; 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: Thu, 06 Feb 2020 10:45:14 -0000

It's not forbidden, it's impossible -- or more precisely, it's a protocol violation to send them for other reasons.  HANDSHAKE_DONE and NEW_TOKEN frames are sent only by servers, and servers don't send 0-RTT.  A client sending them at any time is forbidden.

PATH_RESPONSE is sent only in response to a PATH_CHALLENGE; PATH_CHALLENGE can only be sent in 0-RTT or 1-RTT, and servers don't send 0-RTT.  Therefore, the client can't be responding to a PATH_CHALLENGE while it's still sending 0-RTT.

RETIRE_CONNECTION_ID can't retire the CID of its own packet.  Until the transport parameters have been parsed, the client only has one CID for the server, so it's illegal to retire it.  Once the transport parameters have been parsed, in the "simple" handshake flow, the client shouldn't be sending 0-RTT.  If the handshake requires an extra round-trip, is it possible to keep sending 0-RTT after having processed the Server Hello?

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