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

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Oct 2019 21:07:58 -0700

At the moment, [section 8.1.2 of the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1.2) states that a resumption token can be used "_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._"

But what does "the same server" actually mean?

Some possible answers include:

* a) the same server IP address
* b) the same server IP address and port
* c) any server name that was presented in the certificate provided in the previous connection (the scope of session tickets; see [RFC 8446; section 4.6.1]( https://tools.ietf.org/html/rfc8446#section-4.6.1))
* d) the same server-name
* e) the same server-name and ALPN (the scope of 0-RTT; see [RFC 8446; section 4.2.10](https://tools.ietf.org/html/rfc8446#section-4.2.10))

I'd presume it to be one of a, b, or c, but I think it'd be better to clarify what "the same server" actually means.

-- 
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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Oct 2019 21:48:02 -0700

IIRC, @martinthomson pointed out that the scope of tokens should be as tight as that of the session tickets (i.e. option c), due to the following reason.

Consider the case of a split-server deployment (i.e. a gateway with a single IP address mapping connections to different QUIC servers in the backend, based on SNI). If we are to adopt option a or option b, one of those backend servers might issue a token, that would then be used by the client when connecting to a different backend server that shares the same gateway. This means that the party controlling the server that issued the token can see that the same client connected to a different server, assuming that the party can observe the traffic that goes into the load balancer.

To avoid the leak, the scope of NEW_TOKEN tokens should be at most the set of the server-names that the issuer of the token is authoritative for; which means option c.

-- 
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-546789506

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Oct 2019 23:54:11 -0700

#3156 is an attempt to clarify option c being the choice.

-- 
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-546815354

---

From: Nick Harper <[email-masked]>
Date: Mon, 28 Oct 2019 12:02:11 -0700

I agree that a or b is not restrictive enough based on the example given above.

I wonder if c/d/e are also not restrictive enough though. Consider example.com hosted on multiple CDNs (where QUIC is terminated by the CDN). A client makes an initial connection to example.com (which gets served by CDN A) and receives a NEW_TOKEN token. Later, this client looks up example.com, gets directed to CDN B, and sends the token it received on the connection to CDN A. I wouldn't expect CDN B to be able to process that token.

We could also decide that it's not worth solving the case above. Being overly restrictive in scoping tokens could mean we don't save tokens often enough (resulting in connections being established with no token when we could have used a token), which might be worse than occasionally sending the wrong token to a server.

-- 
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-547098249

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 14:49:15 -0700

@nharper I think that is a performance concern rather than a security concern?

Assuming that it is the case where sending a token does not have any positive impact on performance, I think we might not need to care about that.

We could, but I think it would be hard to draw a line on when sending a NEW_TOKEN token can be considered beneficial enough..., and there is no negative performance impact on sending an unusable token.

-- 
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-547160658

---

From: Nick Harper <[email-masked]>
Date: Mon, 28 Oct 2019 15:03:11 -0700

Agreed, it's a performance concern, not a security concern. If the client sends an unreadable token, worst case is the server sends a Retry packet and we burn a round trip.

-- 
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-547165008

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 29 Oct 2019 00:17:53 -0700

FWIW, the discussion here relates to issue #3111 (PR #3166).

If we are to say that the scope of a token is tied to the identity of the server (i.e. server certificate), it becomes impractical to use token-based greasing for hosts that are not hosted by multiple entities (i.e. multi-CDN use-case). This is because owners of such hosts would not want to see an additional round-trip due to Version Negotiation packet being sent in response to an unknown version.

If we are to say that the scope of a token is a tuple of the server identity and the server address, maybe that becomes an non-issue, as we can assume that the tuple uniquely identifies the operator of the server.

-- 
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-547288801

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2019 20:58:56 -0700

I think that #3166 is good enough.  There are lots of ways to slice this and what is proposed there seems like the most tractable.  I'm sure that it's not perfect, but I don't think that there will be a perfect answer here.

-- 
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-547729325

---

From: MikkelFJ <[email-masked]>
Date: Thu, 31 Oct 2019 01:31:24 -0700

As I wrote in https://github.com/quicwg/base-drafts/pull/3166/files#r341003819
I think there is an aspect of certificate privacy where you can reconnect with a different server certificate after you obtain a secret salt. Making "same server" too narrow would prevent the privacy benefits of such an approach.`

Publishing a link between such certificates would kind of defeat the point, so there is a chicken/egg problem here. However, if the client has out of band knowledge of another domain that works, it should be allowed to use it.

-- 
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-548264247

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 31 Oct 2019 04:54:51 -0700

@mikkelfj 
> However, if the client has out of band knowledge of another domain that works, it should be allowed to use it.

I think I tend to agree with this statement. And aside from the privacy benefits, I'd note that there is a performance benefit that I am interested in (i.e. https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00).

-- 
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-548335828