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.) It removes the latency benefits of 0-RTT [for that request] and might be 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. -Ben > In conclusion I think there is some thought that needs to go into > handling 0-RTT on the web, but it is manageable. I don't know about > other protocols, but they don't have the same kinds of problem as the > web does with lots of request passing around. Given the benefits here, > I think people will really want 0-RTT, and we are going to have to > figure out how to live with it. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
