Re: [TLS] Comments on EndOfEarlyData

[David Benjamin <[e-mail]>]

On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <[e-mail]> wrote:

> My initial thoughts...
>
>
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
>
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also hope that it will clarify any remaining
> problems of understanding that I have on the issue.
>
> If we see EOED as a stream termination signal, then there seems
> to be a difference in performance for conservative servers that
> want to wait until receiving all 0RTT data before responding to
> the client's request in 0.5RTT communication.
>
> Said otherwise, we want servers to be able to respond with application
> data based on application data from the client and know that that
> that data was not truncated.
>
>
> Thanks, the keyword of "truncated" caused me to understand the intended
> point.
>
> I think this question ends up tying into the more philosophical one of
> whether early data and 1-rtt data are considered "separate streams" or not
> -- if they are separate streams with distinct end/start, then of course one
> wants to detect possible truncation as it happens.  But, if they are
> conceptually the same stream and the boundary between them is "just" a
> bookkeeping operation of key change, then there is no need to be concerned
> about detecting truncation; the application just continues reading in data
> and replying when complete application protocol requests are received.
>

Truncation detection is meaningful in both cases. We rely on KeyUpdate
being protected and tied to the immediately preceding record (by way of
sequence number). Otherwise an attacker could toss out chunks in the middle
of the stream immediately before a KeyUpdate.

David