On 05/23/2017 01:36 PM, David Benjamin wrote: > On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk <[email protected] > <mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
