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

Kazuho Oku <> Tue, 27 August 2019 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D40D612009C for <>; Tue, 27 Aug 2019 00:52:49 -0700 (PDT)
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 B1Z9CS0BwkwO for <>; Tue, 27 Aug 2019 00:52:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0039A120090 for <>; Tue, 27 Aug 2019 00:52:47 -0700 (PDT)
Date: Tue, 27 Aug 2019 00:52:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566892367; bh=2UMAZBwdBLL7W9lb52u1buFayRSuDEbSLJUoxlfppkk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MJDMFKMSSi9Msksm+ODOToNigciO//RlQe91CfbUto6qQ9G1wX3sZkYgv3kuZXbsC uCVtHJIns0/M6GHHz0bl4J1HBPVwE7Q3GsGAXtlZVHhlXlH2O4pXNH/4L6tfRpmjM1 gMExEnUesW4k44lQJVp454IG3ik5TYH7mHgWo+v8=
From: Kazuho Oku <>
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_5d64e14f9e3c_48cf3fd9020cd9681457ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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, 27 Aug 2019 07:52:50 -0000

While I agree that endpoints should not leak information that let's the attacker guess a valid token value, I am not sure if we need to require constant time comparison, as suggested by #2993.

I think that the practical defense would be mix a secret seed securely into the hash key (e.g., by using HMAC), much like we do for hash tables to prevent DoS collision attacks. Assuming that we mix a secure seed, the attacker would not be possible to deduce information from the response time of the hash table.

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