On Tue, Mar 15, 2016 at 2:45 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
> I think I agree with that; but maybe would state it as: we can preserve > forward secrecy and replay mitigation for 0RTT data, but at the cost of > read-after-write consistency from a server-side data-store. The store > needn't be transactional, an eventually consistent store could be used: but > the miss-rate would be elevated over what we see today. So it would work > better in the single server case than the many distributed servers case - > but could work for both. > Hmm... my first thought is we can't say all that in a "simple secure 0-RTT" description :) I do think it would help if all that and more were in a more comprehensive document somewhere. > >> The other camp is HTTP-like protocols that terminate all over the place. >> These all seem to be replay-tolerant because random network errors will >> cause random replays, and there is no efficient way to synchronize the >> session cache globally. >> > > I think that's a dangerous position too. Triggering browser retries > requires a certain level of difficulty and has a certain amplification > factor. Sniffing wifi and sending a TCP message is far easier. An attacker > could exhaust things like server-side request throttling limits far more > quickly with the latter than the former. Besides: lowering our own levels > of security because other tools have already done the same is just another > race to the bottom. > I would be happy if we could recommend at least one reasonably secure method for 0-RTT for HTTPS that has a reasonable chance of satisfying the skeptics, and then state that 0-RTT for other protocols, and stateless 0-RTT, needs to be carefully considered for the application.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
