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

Christian Huitema <notifications@github.com> Sun, 13 October 2019 03:26 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 B817D120059 for <quic-issues@ietfa.amsl.com>; Sat, 12 Oct 2019 20:26:13 -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 gMz93hHFlcC5 for <quic-issues@ietfa.amsl.com>; Sat, 12 Oct 2019 20:26:12 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CD912004F for <quic-issues@ietf.org>; Sat, 12 Oct 2019 20:26:11 -0700 (PDT)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id 0E7EA2C0B97 for <quic-issues@ietf.org>; Sat, 12 Oct 2019 20:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570937171; bh=EjLjsLTCDupqReX3RjUGppJ+y+s5ZbPvgXEll5xo3jY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=14LoWKMQRGZ4suNq9mlboRnl/NBsXjVfMlPgaC/IB1TS4AVQmRjRN8XL8O4aIXcX8 66AGvzTDwTjOpPqomTkA1ljx13ZyS5OjT3Mll0WGcHffIx3qpsGy5c6dBnb+EHKpl3 T+V3kkBaAyt87BLC2wVzPwxKPF6eR03hi7t98sbk=
Date: Sat, 12 Oct 2019 20:26:10 -0700
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7K24VXSG36PJVQWGV3V7M6FEVBNHHBOS4WPU@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/541381769@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_5da29952f2cb6_5d423f9862acd96c24632e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/w64vy5HkzA2UmaRm3tUM2iNOmBU>
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: Sun, 13 Oct 2019 03:26:14 -0000

Can someone explain to a dumb guy like me why this is important? We have three paths:

1) Good packet: decrypt, validate, and then process the data in the packet.

2) Stateless reset: attempt to decrypt, fail, find a match for a registered reject token, kill connection.

3) Garbage: attempt to decrypt, fail, do not find a match, do nothing.

I content that (1) and (2) are observable no matter what. If the connection goes on as in (1), further packets can be observed. If the connection stops, absence of further packets can be observed. The behavior after (3) depends on the state -- if the connection is up, further data will come out as in (1). If the connection is down, nothing will happen.

What exactly is the concern?

-- 
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-541381769