On Thu, May 04, 2017 at 11:22:47PM -0500, Benjamin Kaduk wrote: > On 05/04/2017 06:35 PM, Watson Ladd wrote: > > If you are willing to buffer 0-RTT until completion before going to > > the thing that makes the response, you can handle this problem for the > > responsemaker. This will work for most applications I can think of, > > and you need to handle large, drawn out requests anyway. This sounds > > like it would work as a solution, but I am sure there are details I > > haven't discovered yet. > > The server is allowed to buffer the 0-RTT data while processing it and > delay a response until the handshake is completed, yes. (I think this > is the "way to force 1-RTT at the application layer" that Nico wants.)
I'm not up on the details of how 0-rtt works in TLS 1.3. I don't know if there's a way for the server to cause a round-trip to occur, nor if there's a way for the client to then confirm the 0-rtt data in that round-trip. I do think having such functionality would be very helpful for cases where the server runs a) without a replay cache, and b) can accept idempotent and non-idempotent requests. I think always requiring a replay cache is not likely to work out in practice. > It removes the latency benefits of 0-RTT [for that request] and might be Because [for that request] there are no benefits of 0-rtt. > annoying to implement with APIs that only give you a single data stream > (but probably not too bad), but the application layer at the server has > the capability to solve these idempotency/replay problems. > Unfortunately, we are the TLS layer and cannot assume that we control or > can cooperate with the application. Which leads right back to the > "application profile is required" bit, of course. Yes, sure, but the application profile rubber has to meet the road. That usually means that the devil is in the APIs. An application that wants a "dumb secure socket"... just can't have 0-rtt. HTTP should be trivial to profile... if only GET weren't abused here and there. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
