Re: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)

Mike Bishop <> Thu, 13 December 2018 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DC6B130E7E for <>; Thu, 13 Dec 2018 12:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ofTgyOi4cGyI for <>; Thu, 13 Dec 2018 12:16: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 D4152130E7D for <>; Thu, 13 Dec 2018 12:16:51 -0800 (PST)
Date: Thu, 13 Dec 2018 12:16:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1544732210; bh=C0bajWoTV/n0PAnIrlxOLnXLPUNeSvaXPBzY88D3axs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Rxgqs2RhmBskayA82keDp/3TWtULP3IgtDseD00B0kIeSVjQBFw1jb0Bna2P/NLsY Wr1Xen4ZbNr582c/1wQpHPhijYSzq5OM7rUYVNKWdSqsVVmL9W7LjLIH/VMWRn1qQ6 WTKp+NJ4C7YXOswDL3nTcIH64isvHAVhMJnbBmso=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2152/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c12be32c2f32_49003f9d440d45b411998d"; 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, 13 Dec 2018 20:16:54 -0000

I'm not sure the order is (intended to be) normative.  An SR looks like a junk packet that you would otherwise drop, either because it doesn't match a known connection by CID, or because it happens to match a known CID (zero-length helps) but gives a whacko packet number compared to the connection state, or because the packet number looks reasonable but the MAC is bad.

In those situations, you then have to decide whether it's just junk or actually a SR.  So the order is what we expect a logical implementation would do, but not necessarily required.  Can you propose better explanatory text for that?

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