On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. > I don't disagree with that necessarily, but if the client responds by retransmitting in 1-RTT, then you don't have overall at-most-once. -Ekr > > 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
