Re: Structuring the BKK spin bit discussion

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 31 October 2018 00:05 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 0A6FB1277CC for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 17:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 l8mFsS9JrZDn for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 AA0F1130DC7 for <quic@ietf.org>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id e74-v6so16014321ita.2 for <quic@ietf.org>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uHbUHM1vMvfBVz6+p6Y5TbQn4ane+bSQxv6gFDb+im0=; b=LBC0B5CvPkj7pUKnUXFzieOntkDMuUzjW2QHAP6EBsNSNo/m05zKpQ7K67ZpjuD/m0 oe5w77sI/jZCoOTlFM/vEH2uXtcD+4Gw9WmzZ4NOw4rWnyvtIjzaZCH4W1842dlKLURz ulJBNu0RnXzY7AqvWMpowRPnA/SNL2ZiN8ZXaPBqb6fKXUL5O7Eqn4PkKqxDgMwbheT8 tfpzeGitLMfJxPFS2LLK0HT2SguzMUWpGGpdP57JUfYbOV8lLJA6vO68aZKTj6PC7trE JClugw7T7jLHBnsxZh0eKrw6CgJNKgxHhuY8yHGhoMQo47/qXw+4JD1mdGQxwlu9Ph/y 8JMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uHbUHM1vMvfBVz6+p6Y5TbQn4ane+bSQxv6gFDb+im0=; b=cZmMF6wG0Iak/8uENEZbbK7aTi+7WaWrbdia3JbbSbdIQYUf4usSNPYJdd1gSV0txa +DRVLAny69LfxdcUX5sc04nHiiZgUHJ+FnJpcERM7TPYpJq9ta9YNO1tSPhcLOvgsYuB ZVz/YJ45XC3HRjoWgnRlh6lKXLSnF5Lh0SOmu3C1OgrYPXWlqWCNrQXz0dBxc78e2VP6 jU0v60ZvaYzxdP4MqxwJS+LaZXxoJMrIQ7bSRIr82v4jk+ExkEV+NuIQ39RJeZS5eyyw zKhWfjMQKdSZWprlncExmhPRF0KoZ84XN0DWumwXWpDKGETq8oJSQ8LuhaAQjYiB/CJw dZ0A==
X-Gm-Message-State: AGRZ1gJ703PpjtpM7OPQicoj2GTz33K5EcIggG7BTo08gRPLMB5pCUaT hKevjWERDVEa/ZfoPCGuhxVqdb/BZH8tU8cOiT4=
X-Google-Smtp-Source: AJdET5eI5o6CsTVfSCgnXI1KZ/Dm94z8XxQeNYYAR1Mei1Aer01vqwGQtrnYiXCN4Oc9fGFFnx/05L4Yx9MlOFdIXyo=
X-Received: by 2002:a24:3088:: with SMTP id q130-v6mr589627itq.148.1540944329022; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Oct 2018 17:05:28 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CACpbDccP7zw6yUyMs0iyAzByBDjprsoBbwey3c0t7wXEddvrvA@mail.gmail.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> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <HE1PR0701MB23939472CAA7CC7C1CD42BB1E2CC0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <65907d96-a525-dcd0-39cd-678c52d26ab6@huitema.net> <CABkgnnVCveXr2GUsx2ZyKNf08VaCh+Ts-T=5wD3_-8Pqk2xRTQ@mail.gmail.com> <CACpbDccP7zw6yUyMs0iyAzByBDjprsoBbwey3c0t7wXEddvrvA@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 30 Oct 2018 17:05:27 -0700
Message-ID: <CAN1APdcZAK6Kw0b+hB6Z1fZ4xWATmqYXzg--_qFLdKUq7E5zPg@mail.gmail.com>
Subject: Re: Structuring the BKK spin bit discussion
To: Jana Iyengar <jri.ietf@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
Cc: Marcus Ihlar <marcus.ihlar@ericsson.com>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059a34a05797b0f3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2uxft7S1NBnJWXZ5DOWyFMYnOYQ>
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: Wed, 31 Oct 2018 00:05:31 -0000

This might overcomplicate things but a client could perhaps downsample the
spin bit by only changing phase every second time the server does, or other
harmonics. If this is done randomly it could hide some latency.


On 31 October 2018 at 00.52.29, Jana Iyengar (jri.ietf@gmail.com) wrote:

On Tue, Oct 30, 2018 at 3:55 PM Martin Thomson <martin.thomson@gmail.com>;
wrote:

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

Yes, per path makes sense to me. I think the linkability concern here is
weak, but it doesn't hurt any to do this per path.