Subject: Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)

From: Igor Lubashev <[email-masked]>
Date: Sun, 03 Nov 2019 09:46:46 -0800

I see a lot of value in alternative "a or c" for CDNs. The purpose of the token is to prove to the server that the client owns the address. It should not matter why the client received the token (similar to TFO token).

As for the privacy, I do not see a problem. The gateway already sees everything and knows everything. If the backends cooperate, they already know everything. If they do not cooperate, this is no different than a multi-CDN case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549161265

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 03 Nov 2019 20:43:17 -0800

@igorlord 
> As for the privacy, I do not see a problem. The gateway already sees everything and knows everything.

Only when the gateway is encrypting / decrypting the traffic. Counterexample is QUIC-LB, where the gateway just forwards the packets to different backend servers.

> If they do not cooperate, this is no different than a multi-CDN case.

(c) is exactly the same as what we state for TLS session tickets in RFC 1.3, which covers the multi-CDN case. If we want to be more lax, I think we need to present that there is no privacy concerns in doing so.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549223382

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Nov 2019 03:43:23 -0800

@kazuho If gateway does not have the keys, it has no more info than a multi-CDN case. In fact, it has less info -- it cannot tell when the new connection is for the same or different hostname than the one that issued the token.

I am interested in anyone presenting a material reduction in privacy in case (a) that is absent in a multi-CDN case with case (c).  (I am not aware of a way to prove lack of privacy concerns other than making an attempt to find some and falling to do so).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549318400

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Nov 2019 03:48:32 -0800

@igorlord How about https://github.com/quicwg/base-drafts/issues/3155#issuecomment-546789506?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549319955

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Nov 2019 04:00:59 -0800

@kazuho I did see this but am confused where the risk is. If a party can see all traffic going to a specific IP, is the concern that it is giving them some extra information when there are multiple clients behind a NAT?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549323704

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Nov 2019 04:46:02 -0800

@igorlord No.

The concern is on the server-side, where three parties are involved: a) owner of LB (that only sees unencrypted traffic), b) owner of one server behing _a_, c) owner of another backend server behind _a_, who can also monitor the traffic between clients and _a_.

The attack goes like this:
1. _c_ accepts a connection from a legitimate client (through _a_), and issues a NEW_TOKEN token
2. The client reconnects to _b_ (through _a_), using the the token obtained in step 1. At this point, _c_ can tell that who connected to _b_.

Going back to our design principle; we require NEW_TOKEN tokens (and also TLS session tickets) to be sent using an encrypted channel, and to be used only once, because the fact that the client is connecting to a particular server should not be exposed to a third party. In this example, we are violating that requirement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549337407

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Nov 2019 05:27:57 -0800

@kazuho So why is the answer to my question of whether the scheme above gives out extra information only in case of multiple users behind a NAT: no?

If there is only a single user behind an IP, a party that can observe all traffic to load balancer "a" can know who is connecting to "c" and "b" just by matching on the src ip and seeing that they are the same.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549352624

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Nov 2019 05:55:24 -0800

@igorlord 
> If there is only a single user behind an IP, a party that can observe all traffic to load balancer "a" can know who is connecting to "c" and "b" just by matching on the src ip and seeing that they…

I think the hidden assumption in your argument is that the client is connecting to "b" and "c" at the same time. When that assumption is met, I think you are correct that the attack is only viable when the client is behind a NAT.

But it could also be the case that the client first connects to "c", disconnects, then connect to "b" using the token obtained from "c" from a different address. In that case, the attack becomes concerning even when the client is not behind a NAT.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549363852

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Nov 2019 06:57:27 -0800

@kazuho 
> But it could also be the case that the client first connects to "c", disconnects, then connect to "b" using the token obtained from "c" from a different address. In that case, the attack becomes co…

This is an address validation token. It is coded for a particular client address. The client will not use the token if it has migrated to a different address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549392154

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Nov 2019 20:13:41 -0800

> The client will not use the token if it has migrated to a different address. 

The specification is not written as such. Section 8.1.2 states, that _if the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD include that value in the Token field of its Initial packet._ There is no requirement for the client to check it's address (or the network).

I think that the approach used by the specification is correct. In practice, I think we cannot assume that all the clients would correctly deal with their source address explicitly (as well as the change of the address). Besides, a change of source address does not necessarily mean that the client has migrated to a different network. Consider the case where a client goes out of one DHCP network, then returns to that network. In such case, the client might receive a different address, but it is still on the same network. After all, we are requiring the server to associate NEW_TOKEN tokens and the original source address. Then, why not let the server decide if a token can be reused?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549655583

---

From: Martin Thomson <[email-masked]>
Date: Mon, 04 Nov 2019 21:25:33 -0800

For the client, the consequences of a bad guess is a wasted token and (maybe) the wasted bytes.  That's all.  So in general, there is no reason to constrain use of tokens where the client thinks that they might be useful AND that the client is willing to risk linkability between sessions.

The latter condition is where the various linkages come into play, but the point remains that the client is responsible for making an assessment.  This text is about setting a common baseline for that.

If a client wants to extend the set of servers that might be able to link sessions, I think that's OK, but it has to do this on the understanding of what that means.  The server that issued the token might see this new usage and link it to a specific prior context.  Without ESNI, that means things like knowing where previous users are now trying to connect.

As @kazuho says, a client might choose to constrain token use to particular networks, but it doesn't have to.  I might even go so far as to say that they should probably not reuse a token from a different network location, but that depends on having information that I know is hard to acquire.  A requirement that the token only be used from a certain network location wouldn't be implemented because in some cases it couldn't be implemented reliably.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549667932

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Nov 2019 00:40:29 -0800

> The latter condition is where the various linkages come into play, but the point remains that the client is responsible for making an assessment. This text is about setting a common baseline for th…

I think it is a good thing to cover multiple networks because you can hide from external observers. But, if you are on a corporate or government MITM proxy matters are only going to get worse. That said, QUIC cannot possibly accommodate deliberately broken networks.

Also, clients have interests adverse to users as well - for example Google and Facebook need qualified advertising traffic and if QUIC tokens can slip under the Cookie radar, they will. I can't manage a Google cloud cluster without logging in to Youtube on an account that has never signed up for Youtube, and now I can't watch cat videos without getting cluster management commercials which really goes against the point of watching cat videos in the first place (or something roughly equivalent), so on.

So, there is tension in how much to leave for the client to decide vs actual user privacy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-549719955

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 13 Nov 2019 18:08:55 -0800

@kazuho 
> There is no requirement for the client to check it's address (or the network).

@martinthomson 
> As @kazuho says, a client might choose to constrain token use to particular networks, but it doesn't have to. 

Indeed, that's correct, no requirement to check address/network on first use. There is language about reuse that does require the check (but the reuse itself is not required / actually discouraged): "A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface." 

I think I can live with the new language, since it gives clients enough flexibility in case they believe that the server that issued the token and the new server cooperate in managing the tokens (including a belief that they are the same server).  So no objection to the current language in #3156 on my part.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#issuecomment-553690770

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Nov 2019 17:03:44 -0800

Closed #3155 via #3156.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3155#event-2840091769