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

[Ted Hardie <[e-mail]>]

Hi Kazuho,

Some responses in-line.
On Wed, Nov 7, 2018 at 6:58 AM Kazuho Oku <[e-mail]> wrote:

> 2018年11月6日(火) 23:03 Brian Trammell (IETF) <[e-mail]>:
> >
> > 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
>
>