On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
> 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. > Yes. > 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? > The issue isn't encouraged. It's whether we should design the protocol so that it cannot be implemented any other way. -Ekr > 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
