On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote: > On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > As promised: > > https://github.com/tlswg/tls13-spec/pull/1005 > > > > Note: I may have to do a little post-landing cleanup, but I wanted to get > > people's senses of the text ASAP. > > > > Thanks for everyone's comments. I've updated the text to address many of > them and > made comments in Github where I decided not to do so. Can those who have > read > the previous version please take a look?
To me, that reads as gross understatement about the dangers involved in 0-RTT: - The side channel attacks with millions or billions of replays are hard to protect against. This is if the side channels are in TLS library. If not, protecting against that sort of side channels becomes virtually impossible. - Furthermore, with that kind of replay volume, protecting against DoS attacks is virtually impossible. - Even if once-per-server or once-per-cluster replay detection limits the number of replays to few hundred to few thoursand at maximum, where the low-level crypto side channels are much less of a threat, cache attacks can be used to break security (in fact, not sending a mad burst of data to any one server is useful for carrying out these). - 0-RTT Exporters are severly broken unless servers do strict anti- replay. (I left unordered replay out, because I don't see how that is actually created by 0-RTT, as opposed to just being made easier). There are no inherent problems in 0-RTT that I know of that would prevent sending even non-idempotent things like HTTP POSTs over it (however, failure rates are increased if you do). However, as currently described, I would not think 0-RTT is safe for anything except very boring things like protocol banners. I also do not consider it safe enough to implement in anything that actually considers security. Also, on 0-RTT enable/disable: I would imagine that some browsers at first might have an option to disable 0-RTT. However, I expect that over time it will get removed (like what happened with the session ticket support in Firefox), so when serious problem is discovered, there is no option to disable the vulernable feature at all (like happened with tickets in TLS 1.0-1.2) or the disable is far too wide (e.g. disabling whole TLS 1.3 in order to disable 0-RTT). Also, the kind of thing going on here seems exactly how I would imagine the past very bad decisions from TLS WG, that were known to be insecure at the time of specification and where then successfully attacked later, played out. However, I have not read those discussions from the ML archives. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
