Given that 0-RTT and 1-RTT guarantees are very different, it seem important to distinguish the two streams and model them separately.
Of course that does not prevent applications that want to treat them as a single stream, but it is harder to understand the security one gets from such a mixed channel, e.g. some requests may have strong replay protection, others won’t. --markulf From: Benjamin Kaduk [mailto:bka...@akamai.com] Sent: 23 May 2017 18:35 To: Markulf Kohlweiss <mark...@microsoft.com>; tls@ietf.org Cc: Samin Ishtiaq <samin.isht...@microsoft.com>; Antoine Delignat-Lavaud <an...@microsoft.com>; Britta Hale <britta.h...@item.ntnu.no> Subject: Re: [TLS] Comments on EndOfEarlyData 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
