On 05/05/2017 12:04 AM, Nico Williams wrote: > 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.
The server is blindly carrying data for the application. The application can decide to not send any 0.5-RTT data in response to the 0-RTT data, and wait for the regular 1.5-RTT response, if it wants. > 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. If we presume knowledge of (b) then we are forced to consider it at the application layer; a TLS-layer signal would be pretty awkward to manage, and an application-layer signal (or delayed response) seems much more reasonable. > I think always requiring a replay cache is not likely to work out in > practice. I agree. I don't think we should make a claim that 0-RTT data is safe/non-replayable by virtue of requiring that servers implement a replay cache; it's doing consumers a disservice if we expect that there will be servers that don't implement the strict anti-replay measures. >> 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. Yes. > HTTP should be trivial to profile... if only GET weren't abused here and > there. > You might look at https://tools.ietf.org/html/draft-nottingham-httpbis-retry-01 , though I'm no longer confident that's actually the Nottingham document I'm thinking of :( -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
