Re: comments on the spin bit, in lieu of the mic line

Ted Hardie <ted.ietf@gmail.com> Wed, 07 November 2018 01:15 UTC

Return-Path: <ted.ietf@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 C7F431277BB for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 17:15:44 -0800 (PST)
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 McdOZ1LwfBMC for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 17:15:42 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D852E127598 for <quic@ietf.org>; Tue, 6 Nov 2018 17:15:41 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id z33so13241043otz.11 for <quic@ietf.org>; Tue, 06 Nov 2018 17:15:41 -0800 (PST)
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; bh=QkoDicY2EpkHNVktPBc19U6ZFyjpUUCZNRt6x8kNFwg=; b=eXDTmsREdmOKeIouZFpA6joHA1Vj9nnKKn005c7MyiEgHuC0RP32ZR3m6mN4sO8W99 xA1vN5sMxtHyD8/ZJlT5Wxd7+/FKwTPir1W3NveiPpVWeRLGX5m3UYNZM3Syulrsp+Sy VfJiT+u0uSiO4QSGDVy7OQxVXZCrtJFVO95do1AXBFfevXG4lEJMOWoGSGnHUHAx+P+k YJyT3eicqfRkimI9/FHw3+yi0LuVpa8oewYEXc9xxSUnL61FKsIxtT0ankvh01QzSTmH /lIQZybMKVUBBddSS832q/9kulfKK/k8064KWKC65ZNNoIpxfMgGorSfYN4BQtkrPve2 0rHg==
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; bh=QkoDicY2EpkHNVktPBc19U6ZFyjpUUCZNRt6x8kNFwg=; b=Z09N5PalOZ+paiZsduVj3A0zqLE+BuPYMoQyHqZ/Gw0FiK46rA7HpXJZgCRIbg1zCl fD6fBR8qweYx1ZkAySUPPBAaPs+HVfbGQQ83lR+k6FXQALhHLI/tbazq1q+Qo2kIGHbZ /Q4XtD0vD+BcSUsU9lz4KXO9Bbyy9loAHh/buWzxPuW9Y+KgrL1nX98b+sPmvItUCL5M LOxHdIptqYHvEJ8Nw1NiM4jlzhnwndr4qfSn0Vx0ofZl/8lAWYluyCgt0KcBIlctAONG vzeXCuKxc5tH/zGXEg4Ah1zQm/npZplHsYXnTEi8rlS6o8zsRJpe7nCa6XhJlr0DY5H6 bkXA==
X-Gm-Message-State: AGRZ1gIyOoS68ltECMhd14Ft+cWTDybW1V1pULGC/ev6XZLjFdTDPrf8 UiQXAFPH6ac2RxP22Z3MGYuleU8E/n3UBU+Xi2E=
X-Google-Smtp-Source: AJdET5eLGVjc7upm2II6kaz2gv0EHCSfPVyUoaiqIDmz18/soaj49tYr7QRzKZk+xyRsmzMKQ2cBCiL4QcgZa8TWVoM=
X-Received: by 2002:a9d:72a:: with SMTP id 39mr5694961ote.134.1541553340926; Tue, 06 Nov 2018 17:15:40 -0800 (PST)
MIME-Version: 1.0
References: <31F20CF7-3B82-4856-B8AF-485117A10B7B@trammell.ch> <CANatvzyXSTCjp4o2E+Xw2_MvYQ=i3HoCntQ-JW_miZq_yzrbmg@mail.gmail.com>
In-Reply-To: <CANatvzyXSTCjp4o2E+Xw2_MvYQ=i3HoCntQ-JW_miZq_yzrbmg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 7 Nov 2018 08:15:14 +0700
Message-ID: <CA+9kkMC0_bJkypuPNDG8rvUtmHjg6=iLf=sEuSc7S5C0S1nCYA@mail.gmail.com>
Subject: Re: comments on the spin bit, in lieu of the mic line
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Brian Trammell <ietf@trammell.ch>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049d099057a08db67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-08rbbV14cur7XgriQiTpUS5GB0>
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, 07 Nov 2018 01:15:45 -0000

Hi Kazuho,

Some responses in-line.
On Wed, Nov 7, 2018 at 6:58 AM Kazuho Oku <kazuhooku@gmail.com>; wrote:

> 2018年11月6日(火) 23:03 Brian Trammell (IETF) <ietf@trammell.ch>;:
> >
> > Greetings, all,
> >
> > As I might not make it to tomorrow's discussion remotely, I wanted to go
> ahead and say a few things that I would say in the mic line. To the
> questions posed in the agenda:
> >
> >
> > - Yes, we should consider only the 1-bit variant. The VEC protects the
> fidelity of the signal very well (indeed, well beyond the bounds of network
> conditions the transport will tolerate), but (1) Marcus' work in particular
> has shown that even in challenging network conditions, relatively simple
> heuristics at the observers can compensate for not having it, so (2) at the
> cost of two extra bits the marginal value is low.
> >
> > - Yes, the spin bit is clearly fit for purpose. I'll note we've done
> more research on this question than for any other single feature under
> consideration for inclusion in QUIC.
> >
> > - I am not at this time responsible for any sizeable deployment, so I
> can't speak directly to the third question. While I hope we'll hear from
> more implementers during the discussion tomorrow that they intend to
> implement, IMO even just a deployment from Microsoft would be sufficient to
> generate enough spinning flows to make deployment of observers useful.
> >
> > - The spin bit should be included in the specification. It provides the
> continued ability to measure RTT passively in a future world where TCP
> traffic is increasingly replaced by QUIC traffic, at negligible complexity
> cost, essentially zero runtime overhead, with negligible privacy impact,
> and what negligible impact it may have on privacy in certain corner cases
> can be easily mitigated.
> >
> > - As to requirement levels, I'd stick with my own recommendation from
> the earlier thread: client and server SHOULD implement, though server
> SHOULD is IMO marginally more important than client SHOULD.
> >
> >
> > Now some details (presuming, of course, that the discussion gets that
> far):
> >
> > - In any case, both server and client SHOULD independently randomly
> disable spinning on some proportion of connections (1/8 to 1/16) to target
> a given proportion (1/4 to 1/8) of connections spinning, as in [section 4
> of the author's copy of spin-exp](
> https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc..section.4).
> This is to ensure that those endpoints that wish to opt out have a large
> anonymity set to hide in.
> >
> > - If we want to maintain the principle of linkability reduction across
> CIDs, then this non-spinning-state should be independent for each CID. In
> contrast to what's in section 4 of spin-exp, non-spinning spin bits
> shouldn't be set to zero, rather to a random value on a per-CID basis. This
> is easily recognizable by an observer in all cases (client/server
> participate/nonparticipate-1/nonparticipate-0), and reduces the risk of
> ossification around nonparticipant action. (This risk is small, to be sure,
> but we should not clamp a bit to a constant value, if only because we want
> the protocol's design to consistent.)
> >
> > - As to whether non-spinning should be negotiated (see [the appendix in
> the author's copy](
> https://quicwg.org/base-drafts/draft-ietf-quic-spin-exp.html#rfc.appendix.A))
> versus "discretionary", I was originally a fan of negotiation (as it
> provides a better-than-greasing way to exercise the version negotiation
> mechanism), but the rules for maintaining the principle of linkability
> reduction across CIDs become more complicated for negotiated spin, and the
> benefits for observers (i.e., that an observer can classify flows by
> version) become far less clear in the face of that linkability reduction.
> So I would lean toward the discretionary approach for the sake of
> simplicity -- we'll just have to exercise version negotiation by shipping
> version 2 soon after version 1. ;)
>
> Brian, thank you for starting the discussion.
>
> I’m attending, but let me respond here, because I would like to
> “optimize to avoid” people using their brain to parse my broken
> English expressed verbally :-)
>
> If we are to adopt spin bit, my view is that the use MUST be negotiated.
>
> It seemed to me that we agree to the fact that at least in extreme
> cases (e.g. a client or a server behind a intercontinental VPN), there
> is a privacy concern in exposing the spin.
>
>
I pointed out that this privacy concern also exists for the handshake, and
I did not see a response.  Did I miss a mitigation there, or do you agree
that watching the handshake would also disclose this?

Assuming that is true, an endpoint cannot discretionary start exposing
> spin bits, because it exposes to the observer who knows the location
> of the endpoint (which is the common case) how far the peer is from
> it's VPN gateway.
>

While I don't personally see that this reveals any new data beyond the
handshake data, I think making this discretionary handles this cases very
well.  A local configuration that says not to spin when going out a tunnel
interface eliminates this risk completely.  The large window of randomly
disabled other flows means that this discretionary choice is not
highlighted in the data.


> It might be true that negotiating the use makes implementations
> slightly complex. But the complexity should not be used as a reason to
> ignore privacy concerns, especially in case where the additional
> complexity is small.
>
> I think the complexity of including a configuration option for "no
spinning on tun0-like interfaces" is less than the negotiation complexity.
I would even support that being a default configuration, if that allays
your concerns.

best regards,

Ted Hardie



> >
> > If I can't join, have fun tomorrow. Cheers,
> >
> > Brian
> >
>
>
> --
> Kazuho Oku
>
>