Re: Split error codes in two

[Nick Harper <[e-mail]>]

The approach of treating rejected 0-RTT data like it was lost and
retransmitting at the transport layer causes problems. As Victor
mentioned, one of the problems is that the exporter secret changes,
which is a problem for Token Binding if a client attempts 0-RTT Token
Binding and 0-RTT is rejected. In this case, the Token Binding HTTP
header needs to be rewritten to be a signature over the new exporter
value, when the original stream had a Token Binding header that
covered the old exporter value. I agree with Victor that on 0-RTT
reject, streams should be closed.

On Tue, Sep 5, 2017 at 4:31 AM, Victor Vasiliev <[e-mail]> wrote:
> On Tue, Sep 5, 2017 at 7:18 AM, Martin Thomson <[e-mail]>
> wrote:
>>
>> On Tue, Sep 5, 2017 at 8:12 PM, Victor Vasiliev <[e-mail]>
>> wrote:
>> > On Sun, Sep 3, 2017 at 9:55 PM, Martin Thomson
>> > <[e-mail]>
>> > wrote:
>> >>
>> >> The basic idea here - one that I believe that we have agreement on,
>> >> but would like to confirm - is that only applications should be
>> >> cancelling streams.  In short: if the transport kills a stream that
>> >> the application was relying on, the whole application protocol state
>> >> becomes indeterminate.
>> >
>> >
>> > I assume this means only on the wire?  Because you have to close
>> > the streams both when your connection goes down, and when you get
>> > a 0-RTT reject.
>>
>> I forget where this discussion happened, but the current thinking was
>> that 0-RTT reject doesn't result in streams being closed.  Instead, it
>> causes any data that was sent to need to be retransmitted.  Basically,
>> treat it as lost (though not for the purposes of congestion signals,
>> waves hands a little).  Does that make sense?
>
>
> That is what the current gQUIC code does, and it has been historically
> sufficiently problematic that I've been trying to switch us away from that
> behavior.  TLS prohibits automatic resend without explicit opt-in from the
> application, and even then, it's a bad idea.  Application payload may vary
> substantially depending on the state of the TLS connection, so if the
> connection changes, client's presented identity, the exporter secrets used,
> etc, may become different (and in case of exporter secrets, they will).