[TLS] Idempotency and the application developer

[Watson Ladd <[e-mail]>]

Dear all,

Applications have always had to deal with the occasional replay,
whether from an impatient user or a broken connection at exactly the
wrong time. But they've generally been rare, so human-in-the-loop
responses work. Order the same book twice? Just return one of them,
and if you get an overdraft fee, ouch, we're sorry, but nothing we can
do.

0-RTT is opt-in per protocol, and what we think of per application.
But it isn't opt-in for web application developers. Once browsers and
servers start shipping, 0-RTT will turn on by accident or deliberately
at various places in the stack.

At the same time idempotency patterns using unique IDs might require
nonidempotent backend requests. But this is an easier problem than if
we had nonidempotent brower requests: backends are much more
controlled.

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.

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.

Sincerely,
Watson Ladd