Re: [quicwg/base-drafts] Stateless Reset packet sizes should not depend on the maximum connection ID length (#2869)

Martin Thomson <notifications@github.com> Sun, 07 July 2019 23:31 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 C93401201ED for <quic-issues@ietfa.amsl.com>; Sun, 7 Jul 2019 16:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 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, RCVD_IN_MSPIKE_H2=-0.001, 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 oRN_7Ylt9Lk8 for <quic-issues@ietfa.amsl.com>; Sun, 7 Jul 2019 16:31:15 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3764C120250 for <quic-issues@ietf.org>; Sun, 7 Jul 2019 16:31:15 -0700 (PDT)
Date: Sun, 07 Jul 2019 16:31:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562542273; bh=GvnE5322R+484V1RlYRRyWn8VrSDUYPyYMW/SafzShE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=V0CW8xySTLQn269PEO+whCaqijrAb2DzcdYbGOu987uHJyGBqNkzsVWC7CW1ZqKlJ FAhf3+3ZbIpc76qisjws5X4+RBRMcKW9MpCQOCwrNQpPMkiFoFplBTJLFh1SH/xt50 ZKQ1ZqUR9dvpNrkENoRZm9woRhCKuvvZJ+QCdKE8=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY5LN7AOW7X73JEF4V3F6ZUDEVBNHHBXHYKMI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2869/509039192@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2869@github.com>
References: <quicwg/base-drafts/issues/2869@github.com>
Subject: Re: [quicwg/base-drafts] Stateless Reset packet sizes should not depend on the maximum connection ID length (#2869)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d2280c1a5c4b_7a203ffa9accd95c385580"; 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/z7XvlQjZukD_k6uXW8GO-KRajoc>
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, 07 Jul 2019 23:31:22 -0000

I could live with that.  That is a lot harder to write down, but I think that it might work.  I wouldn't make the calculation so complex (just say that the minimum packet size is `maxcid+19` to account for 1 type byte, 1 data byte, and 16 auth tag bytes plus the connection ID length and the one extra byte we lose for the stateless reset) and I wouldn't tie it to a particular role (stateless reset is supposed to be symmetric, it's just that one direction in particular is more likely by far).  We can leave the details to implementations.

I was concerned about clients that were also identifiable by means easier than fingerprinting.  Say someone who deployed client code in their server cluster, where connection IDs are far more likely as a client, for whom any packet (to a client or server) could be readily identified as a stateless reset by virtue of its size.  Profiling by IP address would be easy for someone to do in that case.

-- 
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/2869#issuecomment-509039192