Re: [QUIC] QUIC privacy impact

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

draft-tsvwg-quic-protocol-02 says:

  QUIC connections are identified by a 64-bit Connection ID, randomly
   generated by the client.  QUIC can survive IP address changes and NAT
   re-bindings since the Connection ID remains the same across these
   migrations.

So, can we agree that this statement is very, very vague?

For instance, could I write a QUIC implementation compliant to draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of the connection ID, and e.g. stores the static part permanently on the user’s computer? Or, could I pick as a static part the MAC address? The total ID would still be random. I have difficulties to understand how this sort of ID generation would be different from a “clear text super cookie” and what is defined in the reference you provide.

I am sure that this is not what the current QUIC implementation does. But since we are in IETF context, talking about a potential standard, I am concerned what other implementers of a new protocol could do, and what use cases they could find for this ID.

And if there was some interesting use of having an entirely user-defined clear text value at some constant offset in the packet, for a widely used Internet transport protocol, I am pretty sure some implementers would not care about some MUSTs in an RFC saying “please, please, please select every bit in the ID randomly”.

Or do I miss something obvious?

Michael




From: Jana Iyengar [mailto:[e-mail]]
Sent: Sunday, May 22, 2016 5:20 AM
To: Ryan Hamilton
Cc: [e-mail]; Scharf, Michael (Nokia - DE)
Subject: Re: [QUIC] QUIC privacy impact

Michael,

Just caught up on the SPUD thread, and I'd like to correct something you said there that I'll quote here for context:
"if there is now a new clear text identifier that just happens to be unique per subscriber. What a great improvement for privacy in the Internet! And even better that it seems compatible with QUIC..."

QUIC's connection ID is NOT unique per subscriber. It's per connection. As I said on the other thread, in the single-path case, it reveals no more informtion than TCP. In the multipath case, it effectively reveals no more than MPTCP, since the ID is used to tie the multiple, using MPTCP parlance, "sub-flows", together. It is possible to consider a different design that uses multiple connection IDs for the multiple sub-flows, but to be clear, that makes this new multipath strictly better than MPTCP at privacy-preservation.

At any rate, I wanted to make sure that we're talking about the same issue. I'll also note that it's plain wrong to use the term "clear text super cookie" in relation to the QUIC connection ID (see https://www.techopedia.com/definition/27310/super-cookie for what I think a supercookie is.)

- jana

On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:

That's a design element that should and will definitely be discussed in the WG.

Specifically this applies to use of connection IDs during multipath, and I expect that conversation to happen when we discuss multipath.
On May 21, 2016 6:56 AM, "Ryan Hamilton" <[e-mail]<mailto:[e-mail]>> wrote:
Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <[e-mail]<mailto:[e-mail]>> wrote:
Is it planned to discuss potential privacy implications of the „QUIC connection identifier“ (also named “clear text super cookie” on the SPUD list)?

Thanks

Michael


From: QUIC [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of EXT Ted Hardie
Sent: Saturday, May 14, 2016 1:27 AM
To: [e-mail]<mailto:[e-mail]>; Jana Iyengar; Christian Huitema
Subject: [QUIC] Draft charter

Howdy,
As part of the BoF preparation, we put together a stab at a draft charter.  It's available as html and markdown on github at:

https://github.com/IETF-QUIC/Charter
I've attached the HTML version as well.
It would be great to have some of the discussion on the list before the BoF.  Comments to the list or issues/pull requests at the github repo are welcome.  We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag.

regards,
Ted

_______________________________________________
QUIC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/quic