Re: a proposed way forward was Re: Spin bit decision

[Kazuho Oku <[e-mail]>]

2018年10月3日(水) 16:58 Brian Trammell (IETF) <[e-mail]>:
>
> hi Mikkel,
>
> I think we're having trouble with the many meanings of the word "proxy" here. It can mean at least three things in this context, each of which has different implications for RTT measurement:
>
> (1) Web proxying. The web proxy terminates transport connections, and as such the spin bit would only expose the RTT on the segment between the proxy and its Internet-side peer. Since the whole point of the proxy from a privacy standpoint is to make traffic look like it's coming from the proxy, exposing this RTT is not an issue.
>
> (2) Transport-terminating proxying. Here the proxying happens at the stream, as opposed to the request level. For spin bit measurement, this is equivalent to (1) above. (Note that this is widely deployed for TCP in the form of transparent back-to-back proxies, which won't work in QUIC since the security association protecting the transport is end-to-end.)

FWIW, IIUC TCP proxies that forward HTTPS traffic exist in the market.
At the very least, we care of such proxies in the ESNI draft [1]. The
practical merit of using such proxy is to mitigate DDoS attacks in an
application-protocol-agnostic way, but I would not be surprised if
some of the users are also interested in hiding the true location of
the server.

As you correctly note, such proxy services do not leak the end-to-end
RTT, because TCP is terminated by the proxy, but for QUIC the
transport becomes end-to-end, and it would essentially leak the RTT
between the proxy and the hidden server.

In my view, this should be considered as a degradation in terms of
privacy preservation from TCP to QUIC. I am opposed to having such
degradation, even though it could be considered as a niche. Hence my
argument for SHOULD rather than MUST.

[1] https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-3.1

> (3) Proxy-via-NAT. Here the proxy simply rewrites UDP addresses; in this case, since the transport association is not terminated, the spin bit will expose full end-to-end RTT. Indeed, in this case, endpoints may want to disable RTT measurement.
>
> > On 3 Oct 2018, at 09:45, Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
> >
> >>
> >> At last a concrete argument, thanks ;)
> >> But why would exposing the RTT be harmful in a NAT/UDP-proxy scenario ?
> > Great firewall censorship.
>
> Say more here? I don't see the relevance.
>
> > VPN proxy to bypass streaming restrictions by country.
>
> AFAIK most/all of these are of type (1) and (2), so not relevant to the discussion.
>
> > Hackers that proxy traffic via a legitimate cooperation.
>
> For web traffic, at least, this would probably be of type (1).
>
> > Internet access providers prioritising local traffic.
>
> This can and always will be done via other identifiers, so even if RTT is exposed here, it is of limited utility/threat (depending on which team you're rooting for).
>
> > High latency onion routing traffic.
>
> Necessarily always terminates transport. However, the fundamental design properties of circuit-based anonymity systems do mean that if you're doing something like running a VPN tunnel over ToR (for.. some reason?), then you should turn off the spin bit for traffic within that tunnel. Client opt-outs seem to be mostly sufficient for this, though.
>
> Cheers,
>
> Brian
>
>
> >
> >>
> >>
> >>
> >> _________________________________________________________________________________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or privileged information that may be protected by law;
> >> they should not be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender and delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >> Thank you.
>


-- 
Kazuho Oku