Re: Working Group Last Call for Using Early Data in HTTP

(Sending from the right address this time.)

On Thu, Dec 7, 2017 at 4:08 PM David Benjamin <davidben@google.com> wrote:

> On Thu, Dec 7, 2017 at 12:37 AM Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> Hi Victor,
>>
>> Your question actually suggests an answer:
>>
>> On Wed, Dec 6, 2017 at 1:58 AM, Victor Vasiliev <vasilvv@google.com>
>> wrote:
>> > Do you have a good use case in mind for processing 0-RTT in manner other
>> > than "identical to 1-RTT, buffer or 425"?
>>
>> Not that I have a use case, but that we would be presumptuous to
>> assume that there is something else.  I would hate to see Vary:
>> Early-Data, but it's possible, especially given the alignment of
>> incentives.
>>
>> Imagine a web page that includes some potentially-replay-vulnerable
>> bits inlined.  A 0-RTT response might include a subset of what might
>> be contained in a 1-RTT response, with dangerous parts elided and
>> later filled in.
>
>
> I don't follow how this scenario requires dropping out-of-order early
> data. Perhaps you could write it down in more detail? Let's consider your
> inline vs. out-of-line processing case.
>
> In that case, perhaps server A received out-of-order early data and treats
> those as replay-safe and sends the inlined version. This has side effects,
> but we've had handshake confirmation at this point, so it's okay per the
> second paragraph of section two. Then perhaps those packets are replayed to
> server B such that they are received before the handshake completes. Is
> that your concern? That server would then considers the request early data
> and instead sends out-of-line version, which does not have side effects. In
> total, the side effects still only happened only once.
>
> In fact, it seems acting on the out-of-order early data packets after the
> handshake is exactly the same thing as the deferred processing technique,
> which section three says is okay.
>
> David
>