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

Mike Bishop <> Fri, 21 February 2020 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB90B12006B for <>; Fri, 21 Feb 2020 12:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Status: No, score=-3.682 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, 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 9MIvu5fYbhab for <>; Fri, 21 Feb 2020 12:07:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71A2E12003E for <>; Fri, 21 Feb 2020 12:07:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5ECC88C0FF9 for <>; Fri, 21 Feb 2020 12:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582315671; bh=tJrNlcpg1450L77sDXKQr84JKrAmqZLYJizO6PfOtAw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MC868GL+6EkOtm6ei05UODhjxmFRKMeHC/exaEXy3jGJA6IrRWlO+UUQ3eBwi7Whh hIl1veQNcKR6yXi7LHTzNoY+22S7NNQaGP0I3HNvyTFkCcEdU/sOklW9Y1jP2/3ilw KAFGvIt7xelmojJNiHSfn7dR719GD+tRxqSFgX2k=
Date: Fri, 21 Feb 2020 12:07:51 -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_5e50389750561_19a43faaa3acd9648501d"; 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: Fri, 21 Feb 2020 20:07:54 -0000

I think you need both pieces of logic anyway.  If a peer sends HANDSHAKE_DONE in a Handshake frame, that's an error regardless of role.  You need to check the packet type on receipt.  If a client sends HANDSHAKE_DONE, that's an error regardless of packet type.  You need to check the peer's role on receipt.

The assertion here is that we don't need to expand the packet type check to overlap with the role check.  Then we get into discussion about which of multiple overlapping errors you should use.  We've done that already.

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