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. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
