On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla <[email protected]> wrote:
> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery, > >> even with distributed servers for the origin. >> > > I don't disagree with that necessarily, but if the client responds by > retransmitting > in 1-RTT, then you don't have overall at-most-once. > Obviously this is fine for browsers; retry's make sense there anyway, and so if we prevent mass-replay then there are no new attacks like the side-channels and DOSes. If a client needs to be more careful; with a hard-time limit on ticket use, it can actually reason its way to at-most-once. It needs to wait out the time limit, then do a read; to see if the original attempt succeeded or not, and only then retry. That's a fairly common mode in eventually consistent systems, loss-tolerant protocols and distributed consensus protocols. For example some S3 clients and PAXOS systems work like this. Of course it's very inconvenient to have to sometimes block for 10 seconds (or whatever we pick), in return for a speed up of maybe as much as ~200ms in the "ordinary" case; but it's the kind of trade-off that an instrumentation system might make; like an industrial controller - where day-to-day system liveness is a massive optimization benefit and the occasional interruption is no big deal. Super esoteric, and maybe we shouldn't even think too much about it, but I bring it out because that construction is the only one I've found that gets to at-most-once delivery; and it highlights that the existing system explicitly doesn't and might just be needless complexity (the multiple streams signaling). - Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
