Subject: [quicwg/base-drafts] Force the server and client to remember transport parameters for 0-RTT (#512)

From: Martin Thomson <[email-masked]>
Date: Mon, 08 May 2017 21:29:45 -0700

This includes Victor's recommendation to avoid the client violating server
constraints on operation.  This means that the server that accepts 0-RTT is
required to provide new transport parameters that are compatible with its
previously advertised value, or reject 0-RTT.

I made this easier on servers, by allowing them to advertise different
transport parameters that only apply to 0-RTT.  They include these values in
the TLS NewSessionTicket message, alongside the ticket that is used to resume.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/512

-- Commit Summary --

  * Force the server and client to remember transport parameters for 0-RTT

-- File Changes --

    M draft-ietf-quic-tls.md (4)
    M draft-ietf-quic-transport.md (54)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/512.patch
https://github.com/quicwg/base-drafts/pull/512.diff

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

---

From: ekr <[email-masked]>
Date: Tue, 09 May 2017 05:51:51 -0700

ekr commented on this pull request.

> +transport parameters that the server advertises during connection establishment
+are used.
+
+A server can remember the transport parameters that it advertised, or store an
+integrity-protected copy of the values in the ticket and recover the information
+when accepting 0-RTT data.  A server uses the transport parameters in
+determining whether to accept 0-RTT data.
+
+A server MAY accept 0-RTT and subsequently provide different values for
+transport parameters for use in the new connection.  If 0-RTT data is accepted
+by the server, the server MUST NOT reduce any limits or alter any values that
+might be violated by the client with its 0-RTT data.  In particular, a server
+that accepts 0-RTT data MUST NOT set values for initial_max_data or
+initial_max_stream_data that are smaller than the remembered value of those
+parameters.  Similarly, a server MUST NOT reduce the value of
+initial_max_stream_id.

Why is this required, actually? It seems like you could say "this is what I want next time" without fear.

-- 
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/512#pullrequestreview-37019549

---

From: Mike Bishop <[email-masked]>
Date: Tue, 09 May 2017 15:14:00 -0700

MikeBishop commented on this pull request.

+are used.
+

There's no problem with a server that allows 100KB after 1 RTT advertising 10KB initial for next time.  The problem is if the client has *remembered* 25KB for the 0-RTT flight, and the server wants to turn it down to 10KB after 1 RTT.  The goal is to say turning numbers down on a given connection is never allowed, only up.

-- 
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/512#discussion_r115615311

---

From: ekr <[email-masked]>
Date: Tue, 09 May 2017 15:23:54 -0700

+are used.
+

I got that, but my question is: why?

-- 
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/512#discussion_r115616841

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 May 2017 19:01:04 -0700

martinthomson commented on this pull request.

+are used.
+

The problem is that the client might have already violated that limit.  It could send 25KB of 0-RTT data, only to learn that the limit on the data it can send is 10KB.

This rule prevents the server from creating a situation where a limit has been violated.

-- 
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/512#discussion_r115641130

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 May 2017 22:35:43 -0700

Note that this doesn't remove the need for Karatsuba multiplication in Javascript.  That's a little unfortunate, but JS is very much in the minority when it comes to 64-bit integer support.

-- 
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/512#issuecomment-300378812

---

From: janaiyengar <[email-masked]>
Date: Wed, 10 May 2017 22:40:12 -0700

janaiyengar approved this pull request.

LGTM

-- 
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/512#pullrequestreview-37486709

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 May 2017 17:19:06 -0700

Merged #512.

-- 
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/512#event-1091009055

---

From: MikkelFJ <[email-masked]>
Date: Sun, 21 May 2017 23:07:39 -0700

mikkelfj commented on this pull request.

+are used.
+

If it is not a security issue, why force the client to ensure the server complies with the overhead this involves rather than just require that server to comply and have the connection eventually fail if the server doesn't. There are endless other ways a server might fail to comply that will only eventually result in failure.

-- 
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/512#discussion_r117667342

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 May 2017 23:15:30 -0700

+are used.
+

Let's take the maximum stream number as an example.  

We have two choices: allow the server to set any value, or force the server to provide a value that is >= the value is knows that the client might use.

Given that the client might have used up to the previously-agreed limit, if we allow a smaller limit in the handshake, that creates an unusual condition on the server.  It sets a limit that it can't enforce uniformly.  It has to use two limits when deciding whether the client is misbehaving.  That's a bunch of special code.

In this design, we chose the simpler option.  The only cost is that if the server wants to both *accept* 0-RTT and reduce limits, then it can't.  That little bit of logic is the only place where we have special code.  It can still do things like reset streams and withhold increases to any limit in order to manage its costs.

-- 
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/512#discussion_r117668059