Subject: Re: Revisiting 0-RTT transport parameter negotiation

From: Martin Thomson <[email-masked]>
Date: Tue, 9 May 2017 15:01:34 +1000

I've taken the liberty of raising an issue for this, and a PR:

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

I've copied the design that TLS uses: the parameters are implicit,
just as ALPN is.  I don't think that there is any benefit to including
the values explicitly other than an increase to the ClientHello size
and an extra sanity check.

On 18 April 2017 at 15:41, Martin Thomson <[email-masked]> wrote:
> 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:
>> 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.
>>>
>>>
>>>
>>> -          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 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.
>>
>>