Subject: [quicwg/base-drafts] Remove transport parameters from NewSessionTicket (#1058)

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jan 2018 20:46:42 -0800

Based on feedback from implementers, this is complex and ultimately not that valuable.

Closes #1015.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Remove transport parameters from NewSessionTicket

-- File Changes --

    M draft-ietf-quic-tls.md (3)
    M draft-ietf-quic-transport.md (20)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1058.patch
https://github.com/quicwg/base-drafts/pull/1058.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/1058

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 16 Jan 2018 12:06:50 -0800

vasilvv commented on this pull request.

> @@ -1218,12 +1215,12 @@ ack_delay_exponent (0x0007):
 
 ### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
 
-Transport parameters from the server MUST be remembered by the client for use
-with 0-RTT data.  If the TLS NewSessionTicket message includes the
-quic_transport_parameters extension, then those values are used for the server
-values when establishing a new connection using that ticket.  Otherwise, the
-transport parameters that the server advertises during connection establishment
-are used.
+A client that attempts to send 0-RTT data MUST remember the transport parameters
+used by the server.  The transport parameters that the server advertises during
+connection establishment apply to all connections that are resumed using the
+keying material established during that handshake.  Remembered transport
+parameters apply to the new connection until the handshake completes and new
+transport parameters from the server can be provided.

So, what is our current approach for ensuring that the transport parameter change does not put client in a sudden violation of them?  Do we have a text somewhere else in the text saying that flow control parameters may only increase, or does this still need to be addressed?

-- 
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/1058#pullrequestreview-89231497

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jan 2018 23:54:26 +0000 (UTC)

martinthomson commented on this pull request.

 

The existing text says that if the server accepts 0-RTT it can't change transport parameters to values that the client might violate with its 0-RTT: https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.7.4.2

-- 
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/1058#discussion_r161922440

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 Jan 2018 01:46:31 +0000 (UTC)

We could have a client keep using 0-RTT repeatedly, potentially forever, right?. Does this mean mean that a server is stuck with the params it used for a 1-RTT handshake for all subsequent 0-RTT connections? It's possible I'm missing something basic 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/pull/1058#issuecomment-358167714

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jan 2018 20:54:38 -0800

Yes, that was - at least in part - the motivation for having separate transport parameters.  But the discussion on #1015 suggests that the complexity hit of that exceeds the impact of occasionally having to reject 0-RTT (or not offer 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/pull/1058#issuecomment-358196909

---

From: Patrick McManus <[email-masked]>
Date: Wed, 17 Jan 2018 06:51:22 -0800

mcmanus approved this pull request.

-- 
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/1058#pullrequestreview-89465827

---

From: ianswett <[email-masked]>
Date: Wed, 17 Jan 2018 07:18:48 -0800

I can see the reason for removing the added complexity, but on a practical level, I'm unclear what should occur if a client remembers transport params that the server no longer honors.  If the intent is that the server should honor them, I think it makes sense to state that explicitly.

-- 
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/1058#issuecomment-358336588

---

From: hardie <[email-masked]>
Date: Wed, 17 Jan 2018 17:42:03 +0000 (UTC)

On Wed, Jan 17, 2018 at 7:18 AM, ianswett <[email-masked]> wrote:

> I can see the reason for removing the added complexity, but on a practical
> level, I'm unclear what should occur if a client remembers transport params
> that the server no longer honors. If the intent is that the server should
> honor them, I think it makes sense to state that explicitly.
>
> The current text is this:

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.

So its choices are "honor the transport parameters" and "reject 0-RTT
data", and I believe there are cases where it may need to do both.  In
particular, if it has to turn off a feature that is negotiated uses a
transport parameter, it likely has to move to "reject 0-RTT data" for any
ticket that uses the transport parameter to invoke that feature (see
section 7.3 for the related text on new transport parameters being used to
invoke new features).

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/1058#issuecomment-358336588>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5NXZuecUPHnSzJbzosgSgDx5KyWlks5tLg9WgaJpZM4RfPms>
> .
>

-- 
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/1058#issuecomment-358383651

---

From: ianswett <[email-masked]>
Date: Wed, 17 Jan 2018 17:50:06 +0000 (UTC)

Some transport parameters, like flow control and max stream ID are unilateral. If there are no transport params included with the session ticket, then I believe the only transport params the server receives in the client hello are the client transport params.  So when the server receives the client hello, it doesn't know what transport params the client is using.

Or possibly I'm confused.

-- 
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/1058#issuecomment-358386082

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 Jan 2018 10:56:56 -0800

Two questions:
- Does this mean that the server MUST remember the params along as long as the 0-RTT session key is valid?
- What's the expected action for a server that is unable to honor the 0-RTT params?
I think the text should be explicit about these.

-- 
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/1058#issuecomment-358405928

---

From: hardie <[email-masked]>
Date: Wed, 17 Jan 2018 19:03:26 +0000 (UTC)

On Wed, Jan 17, 2018 at 10:56 AM, janaiyengar <[email-masked]>
wrote:

> The text currently gives the server a choice:

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

So there are three choices: it can remember the parameters for the validity
period, store them in the ticket, or refuse 0-RTT.

>    I think the text should be explicit about these.
If it doesn't know them (because it didn't store them in the ticket and
doesn't remember them),  then it has to refuse 0-RTT.

I think these are the right three choices, so if we need more text to cover
your questions and Ian's similar question, then we should draft a longer
exposition.  If you think these are the wrong choices, of course, that's a
different matter.

>
> —
> You are receiving this because you commented.
> <https://github.com/quicwg/base-drafts/pull/1058#issuecomment-358405928>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5J6Od_tHm33tf3yhERA1ZjEjUcgjks5tLkJ2gaJpZM4RfPms>
> .
>

-- 
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/1058#issuecomment-358407975

---

From: janaiyengar <[email-masked]>
Date: Wed, 17 Jan 2018 19:41:04 +0000 (UTC)

I think I'm agreeing with Ian that we probably ought to be more direct, specifically in stating that the server MUST do one of those two choices if it wants to do 0-RTT. So, I think using MUST and stating why would be helpful.

-- 
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/1058#issuecomment-358419753

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jan 2018 22:19:38 +0000 (UTC)

That MUST already exists, here:

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

The text that Ted cited is (important) context for these stipulations.

-- 
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/1058#issuecomment-358800823

---

From: Sean Turner <[email-masked]>
Date: Sun, 21 Jan 2018 01:08:38 +0000 (UTC)

seanturner approved this pull request.

-- 
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/1058#pullrequestreview-90318980

---

From: janaiyengar <[email-masked]>
Date: Thu, 25 Jan 2018 03:36:12 +0000 (UTC)

janaiyengar approved this pull request.

-- 
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/1058#pullrequestreview-91405182

---

From: ianswett <[email-masked]>
Date: Thu, 25 Jan 2018 04:28:16 +0000 (UTC)

ianswett approved this pull request.

-- 
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/1058#pullrequestreview-91410225

---

From: Marten Seemann <[email-masked]>
Date: Sun, 28 Jan 2018 04:03:36 +0000 (UTC)

marten-seemann approved this pull request.

-- 
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/1058#pullrequestreview-92042725

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 22:09:18 +0000 (UTC)

Making this part of -09, since that is going to make implementation easier, not harder.

-- 
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/1058#issuecomment-361100671

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 14:09:23 -0800

Merged #1058.

-- 
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/1058#event-1445370528