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 > >
- My BoF report: multipath Martin Thomson
- Re: My BoF report: multipath Christian Huitema
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Olivier Bonaventure
- Re: My BoF report: multipath Christian Huitema
- RE: My BoF report: multipath Flinck, Hannu (Nokia - FI/Espoo)
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Behcet Sarikaya
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Roland Zink
- Privacy considerations of multipath (Re: My BoF r… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Roland Zink
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Christian Huitema
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: My BoF report: multipath Jana Iyengar
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Mirja Kuehlewind
- Re: Privacy considerations of multipath (Re: My B… Behcet Sarikaya
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue