On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <[email protected]> wrote: > > 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). > I wouldn't be too fatalistic about it. The speed of light is too slow for human interaction, and 0-RTT is an important and awesome feature that we should make safe and near universal. Some protection is necessary; but it isn't too hard - a single-use session cache, or a strike register, do protect against the side-channel and DOS problems. Combined with a "fail closed" strategy and tickets that are scoped to clusters or servers, these techniques do hard-stop the literal 0-RTT replays, and they are practical. Many of us run systems like that already. > 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. > In this case, I think people see the trade-offs differently and that's ok. There's a sense that the risks or cost are worth it. After all, you can mitigate a lot of the risk if you have a team of experts on standby who manually mitigate these kinds of attacks, or more advanced automated response systems. And many big providers do have both of these. What concerns me most is that the 0-RTT interactions here are formalizable and that the messaging interactions can be modeled in TLA+, F*, etc ... but that hasn't been done as it has with the rest of the TLS1.3 state machine. My TLA+ simple model convinced me that what's in the draft doesn't actually work; there's nothing in the messages that allows a server to de-dupe, I wrote up a simple 3-message example of this earlier in the thread, and it seems to hold to the breaking the "X-" header trick that one provider came up with. That already in this draft deployment phase, that can advanced, knowledgable, provider's attempt at a mitigation can be shown to be broken should be cause for alarm. It's not a safe set-up. Here's all I think we need to fix all of this though, in order of priority: For relatively "Normal" clients (e.g. Browsers): * Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT sections. No time-based mitigation, which simply doesn't work. This is the "cost" of doing 0-RTT. * Clients should be the real arbiter of what to use 0-RTT; e.g. never use for POST, etc. This could bear some emphasis. It's important because middle-boxes exist. For careful clients, think about something implementing a transaction over TLS: * If a 0-RTT section is sent but does not result in a successful receipt, that failure needs to be signaled to the client. * In order to fully reason about when that message may later get received, there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all potential middle-boxes in the pipe that may be using 0-RTT. And then separate to all of the above, and lower priority: * There's a contradiction between the obfuscated ticket age add parameter and the desire to use tickets multiple times in other (non-0RTT) cases. We can't do one without defeating the point of the other. Either remove the obfuscation because it is misleading, or move it into an encrypted message so that it is robust. -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
