IETF Logo Mail Archive

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

Martin Thomson <notifications@github.com> Mon, 26 August 2019 23:40 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200CC120808 for <quic-issues@ietfa.amsl.com>; Mon, 26 Aug 2019 16:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHhvB5Z64dEU for <quic-issues@ietfa.amsl.com>; Mon, 26 Aug 2019 16:40:13 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A6F1200C1 for <quic-issues@ietf.org>; Mon, 26 Aug 2019 16:40:13 -0700 (PDT)
Date: Mon, 26 Aug 2019 16:40:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1566862812; bh=M9F45HLKyWK63YnfYOmboKPcK3N4RmOebLC/WZ9sEVo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lO8XaQZSJiUZw6ExHXeSW1HAYft4y0uo6MmuDaVybg44xdVD1Pd44Nyc2qyMrxq5B ErRdlZ8NbPBsZcsCzDnkrIqePOT2G4n8W9+T2B76VcoO5NSPKhQ/i13wbriPlno+tk NfnIbs2gyivZtq66jX3cxhiJFuHgGDbEm+7+8W+E=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5Z2V2S4VULSUI2BFV3OGJEZEVBNHHBOS4WPU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2152/525074690@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2152@github.com>
References: <quicwg/base-drafts/issues/2152@github.com>
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_5d646ddc7ff10_65993fc6610cd96c644830"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/djShfDE1lLbr-QH6Y_IXtDYjmaA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 23:40:15 -0000

> You don't need constant time because you are not replying to the reset. 

That assumes that you don't have observable behaviour that follows the processing of that packet.  What I'm concerned about is being able to measure the time to compare, which gives an attacker a read on the value of the stateless reset token.

I think that it is sufficient for the comparison of each stateless reset token to be constant time, but the process might be cut short if a match is found.  And it might be OK to not check stateless reset tokens if the packet decrypts successfully.  That would all be on the basis that we're protecting multiple discrete items and not a single secret.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2152#issuecomment-525074690

v2.23.0 | Report a Bug | By Email