On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla <e...@rtfm.com> wrote:
> On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh <c...@allcosts.net> > wrote: >> >> +1 but I think we can go further here and specify 0RTT in such a way that >> it only works when the server maintains state, and so that any given 0RTT >> ticket may only be used once (to preserve forward secrecy as much as >> possible within the constrains of 0RTT). >> > > I'm not enthusiastic about this. This seems like it would rule out a bunch > of implementations > which don't need that guarantee. > With 0RTT, it doesn't seem to be possible to have anti-replay of the message itself without some kind of server state. It's also beneficial for cryptographic safety to prevent at-will re-use of the ticket - other-wise the data is subject to the kind of "try and iterate" attacks we've seen be very successful against DTLS because of its tolerance for duplicate and out of order messages. If server state is required, some more good can come of it by improving the forward secrecy of the 0RTT data to match that of regular data; which I think is most important of all. An implementation would have to be willing to sacrifice replay protection, some cryptographic safety and forward secrecy for the 0RTT data. I'm sure there are implementations that would sacrifice these things to get lower latency more cheaply, but should they be encouraged? I'll admit that this is an unfair simplification in this case since it's a more grey area, but "fast, secure, cheap: pick two" is at play here, and many would pick "fast, cheap". -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
