Re: Privacy considerations of multipath (Re: My BoF report: multipath)

Roland Zink <roland@zinks.de> Fri, 23 October 2020 21:40 UTC

Return-Path: <roland@zinks.de>
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 367A63A0967 for <quic@ietfa.amsl.com>; Fri, 23 Oct 2020 14:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.342
X-Spam-Level:
X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de
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 R3mrHW-QZuI4 for <quic@ietfa.amsl.com>; Fri, 23 Oct 2020 14:40:15 -0700 (PDT)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624A23A0978 for <quic@ietf.org>; Fri, 23 Oct 2020 14:37:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603489055; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=yB7nEDL5G0hYNP+1uPJ95bu2rAittmz1Z8Up7zJGP44=; b=CNQTRY0ji+bDvlTEoX291GZLZR9I5TdFCWMJyj29R/Y0KOp3m4VIcvfwK1aSB/lVB2 FCoNzD1y80/ndl3iZ2INcREyO0PptTnfyl5bGyiEWwu0F+lBAk+PnFwKc+9blz5MoH/e +PZ/6ybXWVi2uLCuUphdkfkR+j/g4UKahn5VbgWY0BU8JN0rVaEuOKlaEkZ7sW7lql6G EbswS7wkpCGEZYvLKwRXktnMHsuuYAaLsjcoN4drNzy1A/YzwLnZKZ78sXD6tY+Oxkz3 zLD45wVCc0kHcvWcCROv1QOYjYASjoDG5wKLXmdgvT/GMGyz1RAb8ufaSgF4mCiAFMRE Cp5g==
X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr4qxJkwZITWW94asib56r5qMcDewxby1q40rWK"
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2003:f4:7700:bf00:f55f:62a6:6170:c0c] by smtp.strato.de (RZmta 47.2.1 AUTH) with ESMTPSA id e032c2w9NLbYhr9 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 23 Oct 2020 23:37:34 +0200 (CEST)
Subject: Re: Privacy considerations of multipath (Re: My BoF report: multipath)
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: QUIC WG <quic@ietf.org>
References: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com> <5741601d-7e67-898e-5840-70feceb994e9@uclouvain.be> <CALGR9oZW0s6c6+N+3R8bD17yPBPQa4E_cVOaTOSNTVQPYy6sUg@mail.gmail.com> <CAC8QAcditJ0nzdCNHOhi-1xtezoXb0u=hrGBWtZ3Cj3XP6CW4g@mail.gmail.com> <CALGR9oZfw5LqfPyZw6Yb8JTmuqi0prTL0f0yT9Rdq6oz5u51fg@mail.gmail.com> <ccbd3f9a-883e-6262-5735-2b9f25c6c6c4@zinks.de> <CALGR9oaw_-dbYSu5oN1Usvwr2h8wp-gvcmzx+0+2HJM-4Ac+4A@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <c09ff2f3-771b-11df-68f3-c690efa998c7@zinks.de>
Date: Fri, 23 Oct 2020 23:37:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <CALGR9oaw_-dbYSu5oN1Usvwr2h8wp-gvcmzx+0+2HJM-4Ac+4A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------79C146E433F74499F9DA7271"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SiCW1BTk_3IllYAWPDo9RmRrp5c>
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: Fri, 23 Oct 2020 21:40:17 -0000

Hi Lucas,


1)  Just opening a second QUIC connection is not enough as it will most 
likely use the same path as the first. Some API to list interfaces and 
their properties is needed. Then the second second connection can be 
bound to the desired interface. If for example you want to check the 
available WiFi networks in Android then you need location permissions 
and the user needs to grant them and can revoke them anytime. In 
addition you need to write some legal text what you do with this data.


2) Is probably similar to 1) but may use some system library to do the 
job and hide it from the application itself.


I can't speak for others but my expectation would be that some OS-level 
API should abstract network layer information when possible. Still and 
e2e solution will reveal the clients changing external IP addresses on 
the server side. A longer lived multipath connection may be used to 
track the user.


Regards,

Roland


Am 23.10.2020 um 22:31 schrieb Lucas Pardue:
> Hi Roland,
>
> On Fri, Oct 23, 2020 at 8:34 PM Roland Zink <roland@zinks.de 
> <mailto:roland@zinks.de>> wrote:
>
>     A application works with a single connection most of the time. As
>     application developer you probably can't afford to put any effort
>     in improving this when it isn't absolute necessary. If you do it
>     on the application layer then the application may also get
>     location information out of it, like IP addresses or WiFi names,
>     and this is a privacy issue.
>
>
> This is an interesting thought and I wonder if you might be able to 
> elaborate some. The userland QUIC libraries I'm familiar with require 
> applications to do a lot of their own lifting with regards to the network.
>
> I'm particularly interested whether there is any difference say between:
>
> 1) An HTTP/3 client application that wants to open two QUIC 
> connections using a userland QUIC library.
>
> 2) An HTTP/3 client application that wants to open one multipath QUIC 
> using a userland QUIC library.
>
> Is the expectation here that there is some TBD OS-level API would 
> abstract network layer information from the application in the name of 
> privacy?
>
> Cheers
> Lucas
>
>