IETF Logo Mail Archive

Re: Structuring the BKK spin bit discussion

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 30 October 2018 07:01 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF595128C65 for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 00:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Aj_CackDgwNo for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 00:01:03 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA27A124BE5 for <quic@ietf.org>; Tue, 30 Oct 2018 00:01:02 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id u68so2638135qkg.9 for <quic@ietf.org>; Tue, 30 Oct 2018 00:01:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=w2veH7Z5NC7cC4io5Th0AA5shcBoGKr61wPZ8jy0mS4=; b=puWXVBQNtJyo0g3KEjcIxdR70PooZ+UYOHD3fpiAfS7IQzYKPIY/EDtlbsZ8p9RLue t9TD7t4awKvgh+lAzTjxUGbuqLA914mdv4LmO97yChHNPqymRFsFFOGPT2yUMR9zheC8 uJdfi5MY6+euKm9/aSFgHNjx56NMNHg4u8oZP9es+z2Aol/Z0/UEOHGX7YXTzuQ+eT7K 4WjOacxe3Sv0nHmgB+c6kXSwJY4XFO+e3Hi5gv8Nu+LDjnIxTY9iP052im/bFZxO9l1m cqBpyOwGWI2nJ/VfA6RYOKBhW3/kkceUCtHNqpMYRCHuglFwmmFBgBMMALsFDXWyZspO y77g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=w2veH7Z5NC7cC4io5Th0AA5shcBoGKr61wPZ8jy0mS4=; b=OG0Lulb2Ar7yDKd5pBxcqTnTfQ1TOoVoSlPzT3RG4X5vGD/psTJlynoDxuB2DuPmgn xIssoiDrvgTSwQn5YPhyIWB3aMNXVKa1Ap1NiGkgBfMNEFWWJMdEfksVtDHsM3XjnN59 +qQuesa+fGFfwOHr/x64bW+B8X83sUr6KYKR9uHu24TXcEfQwUFGLIMQ43vBV5xydrmq AIevZJzz8rD9KZv21lb4cyM47Lt8Q83niPlr+Ioy4OG3xam6BUzFi6MZOFeLgLyC7Afw 65Ge9tgrpIXG3poLWvfbMIZEnbuNGk7/5V/wIu0+UUR5DfTMorYg3ymW1BIgYvHSHt/Q A+rw==
X-Gm-Message-State: AGRZ1gJCPMJDt3f7LC/W/mYeLoc8HJuWmjIhbHYb8qzIQzLOtmZUvNlF 4Xe0URGCziq1BR70dsdXhrJ2VyIa
X-Google-Smtp-Source: AJdET5cRBbsx+Ujm9l4V1K1yF3BryWjvFCHDX8/UjyZP09qliKbNubVyMvmqA6JDbA69JMNX+U/+DQ==
X-Received: by 2002:a37:2bcf:: with SMTP id r76mr14347679qkr.218.1540882861993; Tue, 30 Oct 2018 00:01:01 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.61]) by smtp.gmail.com with ESMTPSA id h49-v6sm17289214qth.32.2018.10.30.00.00.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 00:01:00 -0700 (PDT)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Christian Huitema <huitema@huitema.net>, "quic@ietf.org" <quic@ietf.org>
Subject: Re: Structuring the BKK spin bit discussion
Thread-Topic: Structuring the BKK spin bit discussion
Thread-Index: ATk3NTQ0ZtY1VqWVb0gqyyB8bFiFRjhEMDExM0ZBNEV3VC12LTQ2MjRDN2MxODGr/hIiyg==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 30 Oct 2018 07:00:57 +0000
Message-ID: <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net> <CABkgnnU7W-_o_EGZWpJvTGRSm0KiL-hS7q_oQ6kT3LBoNKHGhw@mail.gmail.com> <5E1AB9AC-D24F-4E0D-9925-57816C5314A4@trammell.ch>, <a088c411-1acc-8b0f-fc1b-8c79ce6f1cd7@huitema.net>
In-Reply-To: <a088c411-1acc-8b0f-fc1b-8c79ce6f1cd7@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766E6B29792BB4401FF38F0ACCC0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qrGq-pJHYNpOKDS4ymJUN3-0Ej8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 07:01:06 -0000

In the Netflix case it just takes 16 connections by the same user, or less when multiple users originate from the sane IP range. Is it really practical (and thus worthwhile) to hide probabilistically as in Huitemas PR?

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Christian Huitema <huitema@huitema.net>
Sent: Tuesday, October 30, 2018 5:27:47 AM
To: quic@ietf.org
Subject: Re: Structuring the BKK spin bit discussion


On 10/29/2018 3:58 PM, Brian Trammell (IETF) wrote:

hi Martin, Christian, all,



On 29 Oct 2018, at 23:29, Martin Thomson <martin.thomson@gmail.com><mailto:martin.thomson@gmail.com> wrote:

On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <huitema@huitema.net><mailto:huitema@huitema.net> wrote:


I think the strongest objection to the spin bit was put up by Marten during the last interim: measuring the RTT with the spin bit discloses the use of hidden path segments like VPN. This issue was not discussed during the privacy analysis.


I had assumed that was part of the analysis and it was covered by the
assumption that spinning could be disabled


+1. Probabilistically disabling spinning, which seems necessary if we want some grease to help us reserve the right to change the semantics of the bit at the spin bit's location in the wire image, should ensure that endpoints that want to disable spinning for their own reasons will have a large anonymity set to hide in, even in a future with perfect implementation and deployment of the spin bit.


I opened PR https://github.com/quicwg/base-drafts/pull/1931 to discuss this.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email