On Thu, May 4, 2017 at 4:58 PM, Nico Williams <n...@cryptonector.com> wrote: > On Thu, May 04, 2017 at 04:35:10PM -0700, Watson Ladd wrote: >> 0-RTT is opt-in per protocol, and what we think of per application. > > Yes. > >> 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. > > It should be up to servers whether a request is allowed with 0-rtt.
Which server? It's possible that the backhauls from the server the TLS connection is made to to the server actually responding to the request do not distinguish 0-RTT from other data. Opportunity for administrative bloopers is immense: even if the responding server rejects 0-RTT, the server proxying requests won't necessarily know that inline as it is reusing the connection. <chop> > >> 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. > > Yes. > > In particular there has to be a way, either in-TLS, or at the > application layer, to force an extra round-trip to confirm that the > 0-rtt data was not an unintended replay. One can always reject... unless I am misunderstanding the suggestion. > > Nico > -- -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
