Re: [quicwg/base-drafts] Method for associating stateless resets with connections is unclear (#2591)

Martin Thomson <> Tue, 07 January 2020 04:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC6C0120045 for <>; Mon, 6 Jan 2020 20:15:42 -0800 (PST)
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_IMAGE_ONLY_32=0.001, 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 Rf9kS3WoeXVy for <>; Mon, 6 Jan 2020 20:15:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB4B4120123 for <>; Mon, 6 Jan 2020 20:15:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F3CDF520924 for <>; Mon, 6 Jan 2020 20:15:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578370539; bh=AZhKFLjEmpRYNU0+5yWCktdaEb92iqapyJVlwRzq8W8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XDBwnp4ya5Hr8dX10kNRfvqdPRHeNJnHrrumTIu4ZY1hMWOj20ATVZbbmY1rfG4mk /Pf/fYGjVwPxg5fkg2YW4Jfs78hkFleTD2VXWxDz6cn9Flxjqz1nxA45vuhiAtvGB7 IbFW39aLArkWBAmnj2zofhryyCCuaIhAL83fSYNQ=
Date: Mon, 06 Jan 2020 20:15:39 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2591/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Method for associating stateless resets with connections is unclear (#2591)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1405ebe5182_417b3fdedf6cd95c2309d8"; 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, 07 Jan 2020 04:15:43 -0000

Looking again at this, the description is somewhat narrower than this issue implies.  The text says:

> The endpoint identifies a received datagram as a stateless reset by comparing the last 16 bytes of the datagram with all Stateless Reset Tokens associated with the remote address on which the datagram was received.

([Preceding text]( provides a more complete description of this process.)

I understand that some implementations just have a single table, and that's OK with some caveats. The text here points away from that by suggesting the use of a table of *remote addresses*, not tokens.  At that point, the number of tokens to search through might use a second table, but they might not need to in many cases.  A linear search over a short set of tokens - using constant-time comparisons - is more likely to be correct.  

Lookup tables have less-than-ideal side-channel properties that might make it tricky to implement correctly.  (Kazuho had some nice ideas about the use of a PRF in the process to mask the lookup, but I don't expect that many people will find that approach obvious).  At this stage, I'm inclined to say that the text we have is closer to "right" and that suggesting the use of a table is likely to fail.

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