Subject: Re: [quicwg/base-drafts] Initial size of dynamic table (#1530)

From: Martin Thomson <[email-masked]>
Date: Mon, 06 Aug 2018 03:54:18 -0700

If the server has to remember what value was associated with 0-RTT, can't we agree on that?

That is, if the client attempts 0-RTT and the server accepts it, the value is set to the 0-RTT value.  We require that both peers remember the value from before, as we agreed in Montreal, so that's easy.

If 0-RTT is rejected, then it's a full handshake and they can all use the 1-RTT values.

In HPACK, we require the first header block that uses the dynamic table to include a table size update, because the table is assumed to start at 0 size (the default; also, settings might not be around when you send that header block).  In QPACK, you always know how much space there is - even if it might later increase - so why not use that?

-- 
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/1530#issuecomment-410669757

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 06 Aug 2018 06:28:37 -0700

What if we have a fixed 0-RTT value?  That is, if the server is willing to accept 0-RTT connections, its dynamic table size is at least `$SOME_VALUE`.  This value can be increased in `SHLO`.

-- 
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/1530#issuecomment-410707725

---

From: Martin Thomson <[email-masked]>
Date: Mon, 06 Aug 2018 17:49:09 -0700

@dtikhonov, that's exactly what is being proposed.  `$SOME_VALUE` is determined by SETTINGS from the previous connection and new SETTINGS can be sent to increase that value.

I don't think that we should fix a value in the spec, if that is what you were implying.

-- 
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/1530#issuecomment-410897261

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 06 Aug 2018 18:28:46 -0700

I did mean a fixed value in the spec.

-- 
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/1530#issuecomment-410903209

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Aug 2018 00:16:39 -0700

I don't think that we could possibly agree on a value to standardize here.  Servers and clients already have to remember things; I don't think that's a problem 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/1530#issuecomment-410958499

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Aug 2018 01:49:56 -0700

@martinthomson 
> That is, if the client attempts 0-RTT and the server accepts it, the value is set to the 0-RTT value. We require that both peers remember the value from before, as we agreed in Montreal, so that's…

+1.

Having the same rule as we have for other limits (e.g. initial_max_bidi_streams) leads to less confusion.

-- 
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/1530#issuecomment-410983255

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Aug 2018 16:01:19 -0700

While I do think that having the table initialize to zero and requiring an explicit size change from the encoder is probably the least bug-prone, I'm willing to save the two bytes and specify that the table begins at the decoder's maximum permitted size as of... whenever.

-- 
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/1530#issuecomment-411580742

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 09 Aug 2018 13:37:13 +0000 (UTC)

So the text in #1642 looks fine, but I would like a clarification (or confirmation):  Is the 0-RTT dynamic table size presumed by the client implicit?  That is, the client says: "let's use the table size we used before -- you know the value I mean!"

In that case, how can the server ever reduce its advertized table size without rejecting all 0-RTTs for a period of time?

-- 
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/1530#issuecomment-411758145

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 09 Aug 2018 08:13:41 -0700

> In that case, how can the server ever reduce its advertized table size without rejecting all 0-RTTs for a period of time?

TLS session ticket has (or should have) a space in which you can store arbitrary data.

So generally speaking, a QUIC stack will store TP, table size, etc. in the session ticket. When it receives a session ticket, the stack consults those variables, and either adopts those variables and accept 0-RTT, or send a new set of settings at the same time rejecting 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/1530#issuecomment-411793086

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 09 Aug 2018 08:20:20 -0700

I see.  This is very helpful.  Thank you!

-- 
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/1530#issuecomment-411795463

---

From: mirjak <[email-masked]>
Date: Thu, 09 Aug 2018 16:16:04 +0000 (UTC)

That should probably be documented somewhere... applicability statement?

-- 
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/1530#issuecomment-411813869

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Aug 2018 10:52:28 -0700

It's a requirement of the TLS implementation, not an applicability consideration for protocols that might want to use QUIC, so I'd be more inclined to see it called out in the TLS draft.  It seems to belong in the more general category of "TLS stacks used for QUIC require the following features which aren't necessarily required for TLS/TCP".

Note that it's #1641 that extends that behavior to the HTTP settings as well as the QUIC transport parameters, so that part is not in the doc yet.

-- 
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/1530#issuecomment-411842282

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 09 Aug 2018 15:26:11 -0700

Note also that while we have two mechanisms for communicating the states of the previous connection (i.e. TLS session ticket and QUIC token), the latter cannot be used for this purpose because tokens are not protected by the handshake. An attacker can mount a cut-and-paste attack to bind a token obtained from a different connection to the victims handshake.

-- 
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/1530#issuecomment-411917732

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Aug 2018 18:30:07 -0700

@kazuho is right.  The token needs to carry its own authentication, but that isn't incorporated into TLS.  We should mention that explicitly.

Though you could pack stuff into a token and then authenticate it by adding a hash of that data to the session ticket...

-- 
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/1530#issuecomment-411947795

---

From: mirjak <[email-masked]>
Date: Fri, 10 Aug 2018 02:14:12 -0700

What I was talking about for the applicability statement was the fact that you can use the session ticket to store information (e.g. TP) if you don't want to/can't store them at 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/1530#issuecomment-412026152

---

From: afrind <[email-masked]>
Date: Wed, 22 Aug 2018 08:42:04 -0700

Closed #1530 via #1642.

-- 
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/1530#event-1803007636