On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote: > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > - 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.
Yup. There are no known reasons that prevent at-most-once 0-RTT delivery, even with distributed servers for the origin. Of course, this impiles that there is some small-enough spatial scope for 0-RTT, so servers in scope can reach global consistency in acceptable time (which also sets the server timeout!) Latencies within a single datacenter should be pretty low, and routing should be pretty sticky between datacenters. > 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. Yeah, for clients that are as careless with HTTP as browsers, sending POSTs in 0-RTT data is very bad idea. > 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. This is already required in order to implement HTTP semantics. E.g. so that if 0-RTT section contains POST request, the HTTP library can signal its client "failed: connection to server lost before reply was received" (and retry GETs, PUTs and DEETEs). > * 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. Isn't that potentially multi-party problem if middleboxes are involved? > 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. The purpose of obfustication is not to hide sibling sessions. The client already blows its cover by using the same session ID twice. The purpose of obfustication is to hide the parent session. Are you talking about attackers being able to determine the rate of client clock? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
