On 05/23/2017 01:36 PM, David Benjamin wrote: > On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <bka...@akamai.com > <mailto:bka...@akamai.com>> wrote: > > > 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. >
Right, but that's also provided for all TLS records by the same mechanism. The counterproposal here seems to be for the server application to consider all the 0-RTT data as a coherent chunk and provide a single reply to the self-contained application message contained therein. That is, it would not expect an application message to span the 0-RTT/1-RTT boundary. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
