IETF Logo Mail Archive

Re: Structuring the BKK spin bit discussion

Martin Thomson <martin.thomson@gmail.com> Tue, 30 October 2018 22:55 UTC

Return-Path: <martin.thomson@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 C4DBD127133 for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 15:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 K4P6PD1-kgaS for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 15:55:43 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 E78AB124BE5 for <quic@ietf.org>; Tue, 30 Oct 2018 15:55:42 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id p23so12785641otf.11 for <quic@ietf.org>; Tue, 30 Oct 2018 15:55:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OolWPUeB3OyXVME6fj3XOAkoB+SmIiTxaKvRoyE4whI=; b=R9AgJ5LF9bUyy73a6m3mFlhZLbsER1PRCaZQf8/U47mEQmvA6PkR+TzwufLumP+n7J 6hpX8VwM84UFXViBM6hLmE+Wuze3JTD2vzwBf156Hb8IPsa5HT2huSgSp7d2a70k3Y4j p6RS5zLeIdbVZE7jlD9zxhQyayp7OFRo1K+XI3YGllo6T0/qpTI1QrSKVPwvK1svvvim JuLfIVB+D4GEBmpltW9FhmG/qfWp8LalVszVXSzdEfv7iL4KzhLfoK3X+LxlLal7OXUo Pm4Ae3Yu5dfybgW67TsozIz0XFDYqPmFKVxaQFLS2EouPBYJjXNYlKMVhvayMuxKuSFE gO9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OolWPUeB3OyXVME6fj3XOAkoB+SmIiTxaKvRoyE4whI=; b=qvqrQIFwKilphPQ9sqnxw7C0ybKPpd1WHJZYXf+qXDSMoHqSmlcdvEa97Xc7i52rg/ kgCAzSnWc7OEKUG85LJ51zihkotRKJnWkCEP4x8QgNO3MXBSLYpR+eQi77kOSq0/mDxA 0m0upXEguJT6lUfTP4k6+z//lYFdzJEtj0xsZYYiWYtRtt815p8mtSEscgRlfRr3K5vg YqiUV/+kqyycaqxmtYrNHYgaVetyK93ZlApyaA83LfksUAIMH8I+kjQKqG+DZ1DjQw9+ 8hInOQUYLDs37ipWi5VOn4Bpwqtht6dUr5aMFSA3mCixlIh5ZWYO8IZ3/n5FHvZoNYZ3 PHHg==
X-Gm-Message-State: AGRZ1gKngtoP1/5Mdyqj7eCvUIS8meiKFT/B/U50d2BxXXT8tOz7MMFJ am/3aFDmLKjWUOKw55jZDsPoQNLuCwJcTT8DlD6+e+ss
X-Google-Smtp-Source: AJdET5cXEKA5LfCyhZIyrzj8KRNWJ+ssyYslQL4Gdm+OoMS5c8+LPTOsU5KkOZ+IIaTEorH/oyrMzD8k/SWh5IbjoVo=
X-Received: by 2002:a9d:6101:: with SMTP id i1mr439102otj.310.1540940142225; Tue, 30 Oct 2018 15:55:42 -0700 (PDT)
MIME-Version: 1.0
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> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <HE1PR0701MB23939472CAA7CC7C1CD42BB1E2CC0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <65907d96-a525-dcd0-39cd-678c52d26ab6@huitema.net>
In-Reply-To: <65907d96-a525-dcd0-39cd-678c52d26ab6@huitema.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 31 Oct 2018 09:55:33 +1100
Message-ID: <CABkgnnVCveXr2GUsx2ZyKNf08VaCh+Ts-T=5wD3_-8Pqk2xRTQ@mail.gmail.com>
Subject: Re: Structuring the BKK spin bit discussion
To: Christian Huitema <huitema@huitema.net>
Cc: Marcus Ihlar <marcus.ihlar@ericsson.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Ss7PDIKC4p8_kcEaiWKxR6Dwr6g>
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 22:55:45 -0000

On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <huitema@huitema.net> wrote:
> Mikkel is correct, we may not want a purely random per connection behavior, but rather something "random per destination". This would better mimic the opt-out behavior of a privacy-sensitive endpoint, which would always opt out when contacting a specific destination. If I had to implement it, I would not use a PRNG, but rather something compute the hash of a local secret and either the peer address or the peer name. That way, the client would opt out for all 16 Netflix connections, or for none of them.

Or are we looking for random per-path?

That notion would seem to tilt the balance more in favour of the
"discretionary" option over the "negotiated" one on the basis that
spinning/not doesn't become a linkability consideration.

v2.23.0 | Report a Bug | By Email