Subject: Revisiting 0-RTT transport parameter negotiation

From: Victor Vasiliev <[email-masked]>
Date: Fri, 7 Apr 2017 14:58:10 -0400

There was a question <https://github.com/quicwg/base-drafts/issues/126> of
what should the client assume about the server's
transport parameters in 0-RTT case.  As a result of the discussion at the
interim, we arrived to the state where client is allowed to assume either
the
parameters from the previous session, or the default values.  Server may
choose
whatever parameters it wants, and if that's incompatible with client's
assumption of server's 0-RTT parameters, the server may reply with an
appropriate error or RST_STREAM, after which the client is supposed to retry
the connection.

I personally find that this solution has "too many joints", as in, it allows
implementations a wide variety of behaviors, which in turn requires their
peers
to accommodate those scenarios.  The situation with the initial flow control
window is especially awkward.  Server might choose to excuse flow control
violations until the 1-RTT phase is reached, which requires client to
accommodate possible flow control window decrease upon receiving server
hello;
or it might choose not to excuse them, which requires client to retry by
special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after 0-RTT
as
a retry signal.  All of this adds a complexity burden onto implementations,
and
makes comprehensive interop testing very hard.

Instead of the current negotiation scheme outlined in the draft, I propose
that
we adapt a simple scheme similar to what TLS does with cryptographic
parameters
and 0-RTT:
  1) Client sends its vision of server's assumed parameters in the
ClientHello,
     and is expected to follow them in 0-RTT packets.
  2) Server either accepts those parameters, or declines 0-RTT altogether,
     by discarding the 0-RTT data and following up with a full 1-RTT
handshake.
If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot be
more limited than what it accepted from the client.

In this scenario, both the client and the server can use their regular
connection handling logic for 0-RTT data, since both the client and the
server
have a consistent view of server's parameters.  This works well when the
parameters match expectations (most of the time), it's simple to implement,
and
it's simple to test.

  -- Victor.

---

From: "Aron ." <[email-masked]>
Date: Fri, 7 Apr 2017 15:16:02 -0400

+1, FWIW

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 7 Apr 2017 19:57:34 +0000

Yes, this seems to work and is simple enough.  It would also close issue 425<https://github.com/quicwg/base-drafts/issues/425>.

-          Igor

From: Victor Vasiliev [mailto:[email-masked]]
Sent: Friday, April 07, 2017 2:58 PM
To: IETF QUIC WG <[email-masked]>
Subject: Revisiting 0-RTT transport parameter negotiation

There was a question<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_126&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rSuh_KpwiFWKg23604M2iz8TEtH3Z0HBA8ZGZU1-kkQ&s=GhxVMwFtY2K9Xi3SfnKtC2RrCBQK5Co0XRXy9sj9NiY&e=> of what should the client assume about the server's
transport parameters in 0-RTT case.  As a result of the discussion at the
interim, we arrived to the state where client is allowed to assume either the
parameters from the previous session, or the default values.  Server may choose
whatever parameters it wants, and if that's incompatible with client's
assumption of server's 0-RTT parameters, the server may reply with an
appropriate error or RST_STREAM, after which the client is supposed to retry
the connection.

I personally find that this solution has "too many joints", as in, it allows
implementations a wide variety of behaviors, which in turn requires their peers
to accommodate those scenarios.  The situation with the initial flow control
window is especially awkward.  Server might choose to excuse flow control
violations until the 1-RTT phase is reached, which requires client to
accommodate possible flow control window decrease upon receiving server hello;
or it might choose not to excuse them, which requires client to retry by
special-casing QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA shortly after 0-RTT as
a retry signal.  All of this adds a complexity burden onto implementations, and
makes comprehensive interop testing very hard.

Instead of the current negotiation scheme outlined in the draft, I propose that
we adapt a simple scheme similar to what TLS does with cryptographic parameters
and 0-RTT:
  1) Client sends its vision of server's assumed parameters in the ClientHello,
     and is expected to follow them in 0-RTT packets.
  2) Server either accepts those parameters, or declines 0-RTT altogether,
     by discarding the 0-RTT data and following up with a full 1-RTT handshake.
If server accepts 0-RTT, its parameters in the 1-RTT server hello cannot be
more limited than what it accepted from the client.

In this scenario, both the client and the server can use their regular
connection handling logic for 0-RTT data, since both the client and the server
have a consistent view of server's parameters.  This works well when the
parameters match expectations (most of the time), it's simple to implement, and
it's simple to test.

  -- Victor.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 17 Apr 2017 09:32:12 -0700

I like this idea, and I support it. Victor -- do you want to generate a PR
for this or would you like me to?

On Fri, Apr 7, 2017 at 12:57 PM, Lubashev, Igor <[email-masked]> wrote:

> Yes, this seems to work and is simple enough.  It would also close issue
> 425 <https://github.com/quicwg/base-drafts/issues/425>.
>
>
>
> -          Igor
>
>
>
> *From:* Victor Vasiliev [mailto:[email-masked]]
> *Sent:* Friday, April 07, 2017 2:58 PM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* Revisiting 0-RTT transport parameter negotiation
>
>
>
> There was a question
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_126&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=rSuh_KpwiFWKg23604M2iz8TEtH3Z0HBA8ZGZU1-kkQ&s=GhxVMwFtY2K9Xi3SfnKtC2RrCBQK5Co0XRXy9sj9NiY&e=>
> of what should the client assume about the server's
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 15:41:48 +1000

As I said on the other thread, I think that this design isn't quite
right, though the problem is certainly real.

The TLS design doesn't rely on the client sending the server what it
thinks the values are, it relies on the server remembering.  That has
better confidentiality properties, and it is isomorphic with other TLS
0-RTT behaviour.

Note that remembering isn't a chore: the client has to remember the
ticket anyway.  Now it has to remember the ticket and the server
transport parameters.  The server has a choice: it can remember them
or stuff them in the session ticket (or it could decide never to
change them).  The difference being that remembering means that you
don't spend critical early bytes on stuff that you know both sides
already know.

On 18 April 2017 at 02:32, Jana Iyengar <[email-masked]> wrote:
>> 425.
>> There was a question of what should the client assume about the server's
>>