Subject: Re: [quicwg/base-drafts] Binding settings into session tickets (#2790)

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 11:19:53 -0700

I don't think the clients should be choosing whether to remember SETTINGS with tickets.

Imagine the following connections (Cn), on which NewSessionTickets (NSTn) and SETTINGS (Sn) are received in these orders:

C1: NST1, S1
C2: S2, NST2
C3: S3

NST(n) is used to do 0-RTT resumption for C(n+1), and early data is accepted by the server in all cases. The server has correctly remembered the settings that applied to the previous connection to reuse in the new connection.

If the client remembers the tickets without the corresponding settings frames, then when it opens C2, the client will assume the default SETTINGS for early data, and then use S2 for the rest of the connection. Meanwhile, the server assumed S1 for the early data, and S1+S2 for the rest of the connection. In C2, the client sees S2 before NST2, so it saves its current SETTINGS state (which is S2) with the NST. Now, when the client opens C3, it uses S2 for early data, and S2+S3 for the rest of the connection. The server's perspective of settings for C3 is that S1+S2 applies for early data, and S1+S2+S3 applies for the rest of the connection.

If the SETTINGS frame is only optionally bound to tickets, then the client and server will have differing perspectives of which settings apply to a connection. Worse, this view will continue to diverge when tickets are issued and used on resumed connections, because the SETTINGS frame received on a 0-RTT resumed connection is a delta.

The right answer is that the first (and only) SETTINGS frame is bound to tickets. This means that a ticket received before a SETTINGS frame MUST wait for the SETTINGS frame, and also means the server MUST send a SETTINGS frame (if it is going to send NSTs).

-- 
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/2790#issuecomment-517402067

---

From: Nick Harper <[email-masked]>
Date: Thu, 01 Aug 2019 14:32:46 -0700

There are a few more options here:

* When sending SETTINGS, send all values, not just the ones changed from the previous connection (i.e. don't send a delta). Once the client receives that SETTINGS frame, both sides agree on that state for the rest of the connection, but they might not agree on the SETTINGS for early data (it could be the default settings, or it could be the SETTINGS from any previous connection).
* Use the default settings for early data. Both peers will always agree on the settings state and there aren't any ordering concerns between SETTINGS and NST. However, this prevents using anything that depends on SETTINGS in early data, e.g. QPACK or future extensions. (Unless QPACK or a future extension defines some way to remember a value for early data on the next connection.)

-- 
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/2790#issuecomment-517466065

---

From: ianswett <[email-masked]>
Date: Thu, 01 Aug 2019 14:50:49 -0700

Using the defaults for early data would be unfortunate, because early(ie: 0RTT) requests are likely to want to insert entries into the dynamic table.

-- 
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/2790#issuecomment-517471015

---

From: David Schinazi <[email-masked]>
Date: Thu, 01 Aug 2019 15:29:24 -0700

And we would want to be able to use HTTP/3 extensions in 0-RTT.

-- 
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/2790#issuecomment-517480768

---

From: Martin Thomson <[email-masked]>
Date: Thu, 01 Aug 2019 17:23:32 -0700

I had reached the same conclusion as Nick: you have to wait for settings and you have to remember those along with the ticket.  I had completely fail to act on that though.  Good that we have an issue to track this now.

-- 
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/2790#issuecomment-517502630

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Aug 2019 11:59:54 -0700

Closed #2790 via #2972.

-- 
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/2790#event-2588151659