Subject: Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

From: MikkelFJ <[email-masked]>
Date: Thu, 14 Nov 2019 00:49:40 -0800

mikkelfj commented on this pull request.

> @@ -1698,10 +1698,15 @@ encrypted form in the token.
 It is unlikely that the client port number is the same on two different
 connections; validating the port is therefore unlikely to be successful.
 
-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.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable to any server that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  When connecting to a server for which the client retains an
+applicable and unused token, it SHOULD include that token in the Token field of
+its Initial packet.  Including a token might allow the server to validate the
+client address without an additional round trip.  A client MUST NOT include a
+token that is not applicable to the server that it is connecting to, unless the
+client has the knowledge that the server that issued the token and the server
+the client is connecting to are jointly managing the tokens.

I think it needs to be clarified that at a token SHOULD not include a token instead of MUST not. It is easy to imagine cases where the client has a strong belief, which is ultimately wrong. Having a MUST here is too strong a burden to place on the client which does not construct the token. Rather, a server MUST not accept a token that a client incorrect submits.

-- 
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/pull/3156#pullrequestreview-316789676

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Nov 2019 01:45:26 -0800

kazuho commented on this pull request.

> Having a MUST here is too strong a burden to place on the client which does not construct the token. Rather, a server MUST not accept a token that a client incorrect submits.

I am not sure if I follow your logic. This is a privacy concern. What we want to prohibit is the client sending a token to a different server identity, not the server using the 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/pull/3156#discussion_r346212528

---

From: MikkelFJ <[email-masked]>
Date: Thu, 14 Nov 2019 01:57:00 -0800

OK, then I have misunderstood this. Unless covered in neighbouring paragraphs I think this should be explained.

However, if the token is required to appear random and unique, why would there a privacy concern? Due to length, or because appear random is not a realistic 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/pull/3156#discussion_r346218630

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Nov 2019 02:16:19 -0800

The privacy concern is being discussed in the issue, starting from 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/pull/3156#discussion_r346227818

---

From: MikkelFJ <[email-masked]>
Date: Thu, 14 Nov 2019 02:26:18 -0800

I see thanks, even I participated in that, too many things going on I guess.

-- 
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/pull/3156#discussion_r346232971

---

From: ekr <[email-masked]>
Date: Fri, 15 Nov 2019 00:47:28 -0800

I'm not sure that this is the right scoping. Consider that NST is explicitly tied just to the server you connected to, not to any server found in the certificate. Why isn't this "same server name"?

-- 
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/pull/3156#issuecomment-554268588

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Nov 2019 00:55:55 -0800

> I'm not sure that this is the right scoping. Consider that NST is explicitly tied just to the server you connected to, not to any server found in the certificate. Why isn't this "same server name"?

Retry is a server controlled method that can be used for various things including client address validation, but also load balancing or redirects to a more local or somehow better service. Requiring these alternative locations to be tightly coupled to the original connection would work against this.

-- 
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/pull/3156#issuecomment-554271435

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 15 Nov 2019 01:20:43 -0800

@ekr Quoting from [RFC 8446 section 4.6.1](https://tools.ietf.org/html/rfc8446#section-4.6.1), the requirement for NST is:
```
   Clients MUST only resume if the new SNI value is valid for the server
   certificate presented in the original session and SHOULD only resume
   if the SNI value matches the one used in the original session.
```

MUST NOT of added in this PR achieves parity with the "MUST only" statement in TLS 1.3.

Regarding the SHOULD in TLS 1.3, I do not think we need feature parity. Compared to TLS 1.3 running over TCP, it is extremely difficult in QUIC to create a proxy that extracts the SNI and then let's different backend server handle the connection. It is natural to assume that a QUIC server that presents a wildcard certificate to be directly hosting all those server identities.

-- 
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/pull/3156#issuecomment-554279982

---

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

Merged #3156 into master.

-- 
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/pull/3156#event-2840091767