I've just gone through this thread and I'm having a very hard time understanding what the actual substantive argument is about.
Let me lay out what I think we all agree on. 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause connection failures) then a DKG-style attack where the client replays the 0-RTT data in 1-RTT is possible. 2. Because of point #1, applications must implement some form of replay-safe semantics. 3. Allowing the attacker to generate an arbitrary number of 0-RTT replays without client intervention is dangerous even if the application implements replay-safe semantics. 4. If implemented properly, both a single-use ticket and a strike-register style mechanism make it possible to limit the number of 0-RTT copies which are processed to 1 within a given zone (where a zone is defined as having consistent storage), so the number of accepted copies of the 0-RTT data is N where N is the number of zones. 5. Implementing the level of coherency to get #4 is a pain. 6. If you bind each ticket to a given zone, then you can get limit the number of accepted 0-RTT copies to 1 (for that zone) and accepted 1-RTT copies to 1 (because of the DKG attack listed above). Colm, Victor, do you disagree with this summary? -Ekr On Thu, Jun 1, 2017 at 4:59 PM, Colm MacCárthaigh <c...@allcosts.net> wrote: > > > On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev <vasi...@google.com> > wrote: > >> I am not sure I agree with this distinction. I can accept the difference >> in >> terms of how much attacker can retry -- but we've already agreed that >> bounding >> that number is a good idea. I don't see any meaningful distinction in >> other >> regards. >> > > It's not just a difference in the number of duplicates. With retries, the > client maintains some control, so it can do things like impose delays and > update request IDs. Bill followed up with an exactly relevant example from > Token Binding where the retry intentionally has a different token value. > That kind of control is lost with attacker driven replays. > > But even if we focus on just the number; there is something special about > allowing 0 literal replays of a 0-RTT section; it is easy for users to > confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be > replayable, then I feel like we have a hope of producing a viable 0-RTT > ecosystem. Plenty of providers may screw this up, or try to cut corners, > but if we can ensure that they get failing grades in security testing > tools, or maybe even browser warnings, then we can corral things into a > zone of safety. Otherwise, with no such mechanism, I fear that bad > operators will cause the entire 0-RTT feature to be tainted and entirely > turned off over time by clients. > >> >> Sure, but this is just an argument for making N small. Also, retrys can >> also >> be directed to arbitrary nodes. >> > > This is absolutely true, but see my point about the client control. > Regardless, it is a much more difficult attack to carry out. That is to > intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section > and sending it again. > > >> >> >>> What concerns me most here is that people are clearly being confused by >>> the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT. For >>> example the X-header trick, to derive an idempotency token from the binder, >>> that one experimental deployment innovated doesn't actually work because it >>> doesn't protect against the DKG attack. We're walking into rakes here. >>> >> >> Of course it doesn't protect against the DKG attack, but nothing at that >> layer >> actually does. >> >> This sounds like an issue with the current wording of the draft. As I >> mentioned, I believe we should be very clear on what the developers >> should and >> should not expect from TLS. >> > > Big +1 :) > > >> So, in other words, since we're now just bargaining about the value of N, >>>> operational concerns are a fair game. >>>> >>> >>> They're still not fair game imo, because there's a big difference >>> between permitting exactly >>> one duplicate, associated with a client-driven retry, and permitting >>> huge volumes of replays. They enable different kinds of attacks. >>> >>> >> Sure, but there's a space between "one" and "huge amount". >> > > It's not just quantitive, it's qualitative too. But now I'm duplicating > myself more than once ;-) > > >> Well in the real world, I think it'll be pervasive, and I even think it >>> /should/ be. We should make 0-RTT that safe and remove the sharp edges. >>> >> >> Are you arguing that non-safe requests should be allowed to be sent via >> 0-RTT? >> Because that actually violates reasonable expectations of security >> guarantees >> for TLS, and I do not believe that is acceptable. >> > > I'm just saying that it absolutely will happen, and I don't think any kind > of lawyering about the HTTP spec and REST will change that. Folks use GETs > for non-idempotent side-effect-bearing APIs a lot. And those folks don't > generally understand TLS or have anything to do with it. I see no real > chance of that changing and it's a bit of a deceit for us to think that > it's realistic that there will be these super careful 0-RTT deployments > where everyone from the Webserver administrator to the high-level > application designer is coordinating and fully aware of all of the > implications. It crosses layers that are traditionally quite far apart. > > So with that in mind, I argue that we have to make TLS transport as secure > as possible by default, while still delivering 0-RTT because that's such a > beneficial improvement. > > >> I do not believe that this to be the case. The DKG attack is an attack >>>> that allows >>>> for a replay. >>>> >>> >>> It's not. It permits a retry. The difference here is that the client is >>> in full control. It can decide to delay, to change a unique request ID, or >>> even not to retry at all. But the legitimate client generated the first >>> attempt, it can be signaled that it wasn't accepted, and then it generates >>> the second attempt. If it really really needs to it can even reason about >>> the complicated semantics of the earlier request being possibly >>> re-submitted later by an attacker. >>> >> >> That's already not acceptable for a lot of applications -- and by enabling >> 0-RTT for non-safe HTTP requests, we would be pulling the rug from under >> them. >> > > Yep; but I think /this/ risk is manageable and tolerable. Careful clients, > like the token binding case, can actually mitigate this. I've outlined the > scheme. For careless clients, like browsers, they can mostly ignore this; > since they retry so easily anyway, it's no worse. > > But there is *no* proposed mitigation for replayable 0-RTT. So I don't > think that's manageable. Just trying to make a data-driven decision. If > someone presents an alternative mitigation (besides forbidding replays), > I'll change my mind. > > >> Throttling POST requests is fine -- they shouldn't go over 0-RTT, since >> they >> are not idempotent. Throttling GET requests in this manner goes at odds >> with >> RFC 7231. >> > > Throttling GET requests happens all of the time and is an important > security and fairness measure used by many deployed systems. 0-RTT would > break it. That's not ok. > > I don't think it is at odds with RFC 7231 ... which also defines the 503 > status code. > > > Incidentally, guarantee C does solve the throttling problem -- if you get N >> replays, you get promise of 1/(N+1) throttled resource available to you. >> Deployments which do this with GETs may want to deploy the measures to >> make N >> very small. Also, since they already keep track of the state for >> throttling >> purposes, they might add a strike register on top of that. >> > > One could implement a strike register like that, in the same way as a > coordinated throttling system, they have some things in common. Though it > crosses layers. > > I'm all for bounded replay protection, with the bounds being 1 ;-) >>> >> >> Why not 2? What is the difference between 1 and 2? 2 and 3? 3 and 24? >> None >> of the proposed attacks distinguishes 1 replay and N replays in >> qualitative >> ways (as opposed to giant semantic leap between 0 and 1 replay); only in >> how >> much damage you can do, or how much information you can extract from the >> side >> channel. >> > > You keep discarding my points about client control and focusing just on > the number; but there quantitative and qualitative differences. That kind > of argument isn't very productive and doesn't move us forward. But I've > answered above too. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
