Okay, I have to admit that I don't know who to use my mail client correctly and
I've now seen that there are many replies. However, I hope the pointer to the
manageability draft is still somewhat helpful...
On 14.07.21, 19:01, "QUIC on behalf of Mirja Kuehlewind"
wrote:
Hi Stephane,
Hi Stephane,
I just found this older mail and didn't really see a reply, so here a quick
note:
You are right that it's really hard to avoid tracking completely, just because
if one flow stops sending to server but that the same time another flow starts
sending with the same "speed" it likely
IETF QUIC WG ,
Stephane Bortzmeyer , Spencer Dawkins at IETF
Subject: Re: A question about user tracking with QUIC
Hey Spencer, Christian,
On Tue, Jun 8, 2021 at 2:58 AM Christian Huitema
mailto:huit...@huitema.net>> wrote:
On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
Hi, Lucas
On Mon, Jun 7, 2021 at 8:59 PM Christian Huitema
wrote:
>
> On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
>
> Hi, Lucas,
>
> On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue
>
> wrote:
>
>
> Hi,
>
> Speaking as an individual.
>
> Through the lens of server-side observation and linking of
On 6/7/2021 7:51 PM, Spencer Dawkins at IETF wrote:
This all seems very reasonable to me. The other question is about timing -
how urgent do people think this guidance is?
I am not sure about that. The most urgent issue is the tracking via TLS
session tickets, but that's exactly the same
Hey Spencer, Christian,
On Tue, Jun 8, 2021 at 2:58 AM Christian Huitema
wrote:
>
> On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
>
> Hi, Lucas,
>
> On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue
>
> wrote:
>
>
> Hi,
>
> Speaking as an individual.
>
> Through the lens of server-side
On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
Hi, Lucas,
On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue
wrote:
Hi,
Speaking as an individual.
Through the lens of server-side observation and linking of clients, I
think Christian makes astute observations on some common concerns and
Hi, Lucas,
On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue
wrote:
> Hi,
>
> Speaking as an individual.
>
> Through the lens of server-side observation and linking of clients, I
> think Christian makes astute observations on some common concerns and
> QUIC-specific ones. Roy too makes some great
Hi,
Speaking as an individual.
Through the lens of server-side observation and linking of clients, I think
Christian makes astute observations on some common concerns and
QUIC-specific ones. Roy too makes some great additional observations about
the context of discussion.
It seems to me this
On Jun 7, 2021, at 12:00 PM, Stephane Bortzmeyer wrote:
>
> Any specific reference to such a discussion about privacy "against"
> the server? I did not find any.
There have been many discussions about session establishment and
reestablishment. Too many to note. However, "user tracking" is not
Peace,
On Mon, Jun 7, 2021, 10:04 PM Stephane Bortzmeyer wrote:
> > QUIC has a 0 connection ID that disallows migration, so you can do
> > this if you want.
>
> I must confess that I was not aware of this possibility. (Anyway, the
> client can always, unilaterally, tear down the connection and
On Mon, Jun 07, 2021 at 04:36:57PM +0200,
Mikkel Fahnøe Jørgensen wrote
a message of 36 lines which said:
> > a privacy-conscious client may be better by not using connection
> > migration, and resetting to an entirely new connection when the IP
> > address changes.
>
> You cannot do that
On Mon, Jun 07, 2021 at 04:37:45PM +0200,
Mikkel Fahnøe Jørgensen wrote
a message of 26 lines which said:
> Also note that a lot of dicussions have taken place on github issues
> and pull requests.
Any specific reference to such a discussion about privacy "against"
the server? I did not find
On Mon, Jun 07, 2021 at 08:21:24AM -0700,
Christian Huitema wrote
a message of 211 lines which said:
> QUIC does enable trade-offs between privacy and performance, and
> these trade-offs are not well documented in the published RFC.
Do we think it could be a good addition to
I think Stéphane raises an interesting point: QUIC does enable
trade-offs between privacy and performance, and these trade-offs are not
well documented in the published RFC. The main trade-off comes from the
use of session resumption, including 0-RTT. A similar trade-off results
from using
Also note that a lot of dicussions have taken place on github issues and pull
requests.
> On 7 Jun 2021, at 16.20, Stephane Bortzmeyer wrote:
>
> On Mon, Jun 07, 2021 at 03:36:31PM +0200,
> Mikkel Fahnøe Jørgensen wrote
> a message of 37 lines which said:
>
>> User tracking has been
>
> This is why that I suggested (but it may be a bad idea, may be I
> didn't think of everything) that a privacy-conscious client may be
> better by not using connection migration, and resetting to an entirely
> new connection when the IP address changes.
You cannot do that for non-trivial
On Mon, Jun 07, 2021 at 03:36:31PM +0200,
Mikkel Fahnøe Jørgensen wrote
a message of 37 lines which said:
> User tracking has been discussed a lot during the development of the
> QUIC protocol.
User tracking BY THE SERVER? I'm sure the WG left no stone unturned
but I cannot find this
User tracking has been discussed a lot during the development of the QUIC
protocol. That is not say the discussion is no longer relevant, but it has not
been ignored.
For servers, it is necessary to track users across migrations, because you need
to maintain connection state and to maintain
On Mon, Jun 07, 2021 at 01:52:19PM +0100,
Lucas Pardue wrote
a message of 43 lines which said:
> As Robin says, to survive such client IP changes would require QUIC
> connection migration. RFC 9000 Section 9.5 [1] deals with the privacy
> implications of migration.
This section is completely
On Mon, Jun 07, 2021 at 02:46:32PM +0200,
Robin MARX wrote
a message of 127 lines which said:
> Could you give more (technical) details why you feel long-lived QUIC
> connections can allow user tracking, and specifically in the IP-switching
> case?
>
> For an on-path attacker observing
Hi Stephane,
As Robin says, to survive such client IP changes would require QUIC
connection migration. RFC 9000 Section 9.5 [1] deals with the privacy
implications of migration.
Cheers
Lucas
[1] https://www.rfc-editor.org/rfc/rfc9000.html#section-9.5
Hello Stephane,
Could you give more (technical) details why you feel long-lived QUIC
connections can allow user tracking, and specifically in the IP-switching
case?
For an on-path attacker observing encrypted QUIC (at one vantage point),
they shouldn't be able to (easily) correlate migrated QUIC
I was thinking about the privacy risks of QUIC and there is one where
I'm not sure what to think of it, and for which I cannot find any
discussion in the archives of the WG.
Long-term QUIC connections may enable some user tracking, even when
the user changes its IP address, without even needing
24 matches
Mail list logo
