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

MikkelFJ <> Mon, 26 August 2019 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 773DE120119 for <>; Mon, 26 Aug 2019 04:17:30 -0700 (PDT)
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 Dy89vlQxKi_a for <>; Mon, 26 Aug 2019 04:17:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E9961200C3 for <>; Mon, 26 Aug 2019 04:17:28 -0700 (PDT)
Date: Mon, 26 Aug 2019 04:17:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566818247; bh=HeWgOzECUAD8pDRUz4P/gvN1N/X4YIE6cbAAewkKYvw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EcnryqgLOh99Eiq90WGssS7RRic+jN79BD+/hJaU1XjlwdU3/AJf2XWpiJJd/Tswg lKFARax3Sn6KgBZ7vbdO+nA3vALQIPw8tBVg30kilU/je5pXpLibJLPM4okocPF/Jq /baGP4E2US+dYq2GTiy/iWfS75eyOyByyFRHSUfs=
From: MikkelFJ <>
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_5d63bfc77541e_3cbe3f801b0cd96c107178"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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: Mon, 26 Aug 2019 11:17:30 -0000

Depending on implementation it can be very hard to do constant time.

Even if you compare keys in constant time, the cache latency can be much higher. For stateless resets I'd assume a lookup only happens once and then it is removed from, say, a hash table. That is, there is no cache latency difference between a valid and an invalid lookup. Compare this to connectionsID's that are looked up frequently. Here it is possible to guess to valid CID's based on lookup times.

But even if you do not have cache latency issues, you have hash collision issues. This makes a hash table unsuitable. The alternernative is binary tree, or a trie. The binary tree will be have to modified to do log N comparisons for all lookups even if the key is found higher up. And regardless a binary tree is much much slower than a hash table. Tries are very complex to implement correctly and must still be implemented for maximum search path comparison.

Another approach is to timestamp the lookup and busyloop until you reach, say, 100ns of cpu cycles after performaning the lookup in a hash table. This is still faster than a binary tree, but slower than the trie.

I seriously doubt most implementations would go out of their way to make resets effectively constants time.

So the question is - does that make most implementations trivial targets for DoS resets?
And what about guessing CID's?

How can practically protect against this, because trusting the implementation to be constant time is not realistic.

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