Re: [TLS] Additional warnings on 0-RTT data
On Wed, Nov 23, 2016 at 10:44 PM, Christian Huitema wrote: > On Wednesday, November 23, 2016 7:20 PM, Colm MacCárthaigh wrote: > > > > Prior to TLS1.3, replay is not possible, so the risks are new, but the > end-to-end designers > > may not realize to update their threat model and just what is required. > I'd like to spell > > that out more than what's where at present. > > Uh? Replay was always possible, at the application level. Someone might > for example click twice on the same URL, opening two tabs, closing one at > random. And that's without counting on deliberate mischief. > Much more than browsers use TLS, and also more than HTTP. There are many web service APIs that rely on TLS for anti-replay, and do not simple retry requests. Transaction and commit protocols for example will usually have unique IDs for each attempt. But even if this were not the case, there are other material differences that are still relevant even to browsers. Firstly, an attacker can replay 0-RTT data at a vastly higher rate than they could ever cause a browser to do anything. Second, they can replay 0-RTT data to arbitrary nodes beyond what the browser may select. Together these open new attacks, like the third example I provided. -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional warnings on 0-RTT data
On Wednesday, November 23, 2016 7:20 PM, Colm MacCárthaigh wrote: > > Prior to TLS1.3, replay is not possible, so the risks are new, but the > end-to-end designers > may not realize to update their threat model and just what is required. I'd > like to spell > that out more than what's where at present. Uh? Replay was always possible, at the application level. Someone might for example click twice on the same URL, opening two tabs, closing one at random. And that's without counting on deliberate mischief. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional warnings on 0-RTT data
On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson wrote: > On 24 November 2016 at 15:11, Colm MacCárthaigh wrote: > > Do you disagree that the three specific example security issues provided > are > > realistic, representative and impactful? If so, what would persuade you > to > > change your mind? > > These are simply variants on "if someone hits you with a stick, they > might hurt you", all flow fairly logically from the premise, namely > that replay is possible (i.e., someone can hit you with a stick). > Prior to TLS1.3, replay is not possible, so the risks are new, but the end-to-end designers may not realize to update their threat model and just what is required. I'd like to spell that out more than what's where at present. The third is interesting, but it's also the most far-fetched of the > lot (a server might read some bytes, which it later won't read, > exposing a timing attack). I need to work on the wording because the nature of the attack must not be clear. It's really simple. If the 0-RTT data primes the cache, then a subsequent request will be fast. If not, it will be slow. If implemented on a CDN for example, the effort required would be nearly trivial for an attacker. Basically: I replay the 0-RTT data, then probe a bunch of candidate resources with regular requests. If one of them loads in 20ms and the others load in 100ms, well now I know which resource the 0-RTT data was for. I can perform this attack against CDN nodes that are quiet, or remote, and very unlikely to have the resources cached to begin with. > But that's also corollary material; albeit > less obvious. Like I said, I've no objection to expanding a little > bit on what is possible: all non-idempotent activity, which might be > logging, load, and some things that are potentially observable on > subsequent requests, like IO/CPU cache state that might be affected by > a request. > ok, cool :) > >> I'm of the belief that end-to-end > >> replay is a property we should be building in to protocols, not just > >> something a transport layer does for you. On the web, that's what > >> happens, and it contributes greatly to overall reliability. > > > > The proposal here I think promotes that view; if anything, it nudges > > protocols/applications to actually support end-to-end replay. > > You are encouraging the TLS stack to do this, if not the immediate > thing that drives it (in our case, that would be the HTTP stack). If > the point is to make a statement about the importance of the > end-to-end principle with respect to application reliability, the TLS > spec isn't where I'd go for that. > I'm not sure where the folks designing the HTTP and other protocols would get the information from if not the TLS spec. It is TLS that's changing too. Hardly any harm in duplicating the advice anyway. > > I think there is a far worse externalization if we don't do this. > Consider > > the operations who choose not (or don't know) to add good replay > protection. > > They will iterate more quickly and more cheaply than the diligent > providers > > who are cautious to add the effective measures, which are expensive and > > difficult to get right. > > OK let's ask a different question: who is going to do this? > I am, for one. I don't see 0-RTT as a "cheap" feature. It's a very very expensive one. To mitigate the kind of issues it brings really requires atomic transactions. Either the application needs them, or something below it does. So far I see fundamentally no "out" of that, and once we have atomic transactions then we either have some kind of multi-phase commit protocol, distributed consensus, routing of data to master nodes, or some combination thereof. The smartest people I've ever met work on these kinds of systems and they all say it's really really hard and subtle. So when I imagine Zero-RTT being done correctly, I imagine organizations signing up for all of that, and it being worth it, because latency matters that much. That's a totally valid decision. And in that context, the additional expense of intentionally replaying 0-RTT seems minor and modest. My own tentative plan is to do it at the implementation level; to have the TLS library occasionally spoof 0-RTT data sections towards the application. This is the same technique used for validating non-replayable request-level auth. I don't see browsers doing anything like what you request; nor do I > see tools/libs like curl or wget doing it either. If I'm wrong and > they do, they believe in predictability so won't add line noise > without an application asking for it. > I hope this isn't the case, but if it is and browsers generally agree that it would be unimplementable and impractical, then I think 0-RTT should be removed unless we can come up with other effective mitigations. Otherwise it's predictable that we'll see deployments that don't bother to solve the hard problems and are vulnerable to the issues I've described. But let's not be doom and gloom about it,
Re: [TLS] Additional warnings on 0-RTT data
On 24 November 2016 at 15:11, Colm MacCárthaigh wrote: > Do you disagree that the three specific example security issues provided are > realistic, representative and impactful? If so, what would persuade you to > change your mind? These are simply variants on "if someone hits you with a stick, they might hurt you", all flow fairly logically from the premise, namely that replay is possible (i.e., someone can hit you with a stick). The third is interesting, but it's also the most far-fetched of the lot (a server might read some bytes, which it later won't read, exposing a timing attack). But that's also corollary material; albeit less obvious. Like I said, I've no objection to expanding a little bit on what is possible: all non-idempotent activity, which might be logging, load, and some things that are potentially observable on subsequent requests, like IO/CPU cache state that might be affected by a request. >> I'm of the belief that end-to-end >> replay is a property we should be building in to protocols, not just >> something a transport layer does for you. On the web, that's what >> happens, and it contributes greatly to overall reliability. > > The proposal here I think promotes that view; if anything, it nudges > protocols/applications to actually support end-to-end replay. You are encouraging the TLS stack to do this, if not the immediate thing that drives it (in our case, that would be the HTTP stack). If the point is to make a statement about the importance of the end-to-end principle with respect to application reliability, the TLS spec isn't where I'd go for that. > The problems of 0-RTT are disproportionately under-estimated. I've provided > what I think are three concrete and realistic security issues. If we > disagree on those, let's draw that out, because my motivation is to mitigate > those new issues that are introduced by TLS1.3. > >> What I object to here is the externalizing that this represents. Now if I >> have the audacity to >> deploy 0-RTT, I have to tolerate some amount of extra trash traffic >> from legitimate clients? > > > I think there is a far worse externalization if we don't do this. Consider > the operations who choose not (or don't know) to add good replay protection. > They will iterate more quickly and more cheaply than the diligent providers > who are cautious to add the effective measures, which are expensive and > difficult to get right. OK let's ask a different question: who is going to do this? It's a non-trivial thing you ask for. This involves a new connection setup just to send a few packets, and probably a timer so that you can wait long enough for the server to explode. Do you expect to replay before the real attempt? Because that's even less likely to happen. Connections aren't cheap, bandwidth as well. And the time requirement for building such a feature would be better spent elsewhere, not to mention the ongoing maintenance. I don't see browsers doing anything like what you request; nor do I see tools/libs like curl or wget doing it either. If I'm wrong and they do, they believe in predictability so won't add line noise without an application asking for it. If few enough people do this, what makes you think that such a tiny amount of replay would make any difference? Unless you replay with high probability, then the odd error will be dismissed as a transient. This is especially true because most of these sorts of exploitable errors will happen adjacent to some sort of network glitch (the requests at the start of most connections - on the web at least - are pretty lame). Then you all you have done is increased the global rate of "have you turned it off and on again?", which is - after all - yet another opportunity for replay. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional warnings on 0-RTT data
On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson wrote: > OK, let's be clear: I don't agree that the level of paranoia > surrounding 0-RTT is warranted. Do you disagree that the three specific example security issues provided are realistic, representative and impactful? If so, what would persuade you to change your mind? > I'm of the belief that end-to-end > replay is a property we should be building in to protocols, not just > something a transport layer does for you. On the web, that's what > happens, and it contributes greatly to overall reliability. > The proposal here I think promotes that view; if anything, it nudges protocols/applications to actually support end-to-end replay. > The reaction to perceived problems in 0-RTT is disproportionate. You are asking for a license to replay here at some arbitrary layer of the > stack. That's not principled, it's just on the basis that you don't > like 0-RTT and want to innoculate other people's software against the > ill effects it might create. The problems of 0-RTT are disproportionately under-estimated. I've provided what I think are three concrete and realistic security issues. If we disagree on those, let's draw that out, because my motivation is to mitigate those new issues that are introduced by TLS1.3. > What I object to here is the externalizing that this represents. Now if I > have the audacity to > deploy 0-RTT, I have to tolerate some amount of extra trash traffic > from legitimate clients? > I think there is a far worse externalization if we don't do this. Consider the operations who choose not (or don't know) to add good replay protection. They will iterate more quickly and more cheaply than the diligent providers who are cautious to add the effective measures, which are expensive and difficult to get right. That is a perverse incentive, and ultimately users would pay the price. I have the same gut reaction against sending duplicate data and having a sort of "tax on everyone" for the sake of safety as you, it's icky, but I haven't been able to think of another mitigation for the problems that would be as effective. -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional warnings on 0-RTT data
On 24 November 2016 at 13:18, Colm MacCárthaigh wrote: > Can I break this into two parts then? First, do you agree that it would be > legitimate for a client, or an implementation (library), to deliberately > replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a > safety mechanism, to enforce and audit the server's and application's > ability to handle the challenges of replay-ability correctly. OK, let's be clear: I don't agree that the level of paranoia surrounding 0-RTT is warranted. I'm of the belief that end-to-end replay is a property we should be building in to protocols, not just something a transport layer does for you. On the web, that's what happens, and it contributes greatly to overall reliability. The reaction to perceived problems in 0-RTT is disproportionate. You are asking for a license to replay here at some arbitrary layer of the stack. That's not principled, it's just on the basis that you don't like 0-RTT and want to innoculate other people's software against the ill effects it might create. What I object to here is the externalizing that this represents. Now if I have the audacity to deploy 0-RTT, I have to tolerate some amount of extra trash traffic from legitimate clients? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional warnings on 0-RTT data
On Wed, Nov 23, 2016 at 3:03 PM, Martin Thomson wrote: > This seems like too much text to me. Maybe some people would > appreciate the reminder that replay might cause side-effects to be > triggered multiple times, or that side effects are just effects and > those might also be observable. But I think that those reminders > could be provided far more succinctly. > My main goal is clarity, especially to application builders. In my experience the implications of replay-ability are frequently overlooked and it's well worth being abundantly clear. For most builders, those full implications have never occurred to them (why would they?), so it's often not a reminder, but new knowledge. It warrants a big warning label, not FUD, but honestly scary because it is a very hard problem. But still, the text can most likely be shortened some, edits welcome. > The bit that concerns me most is the recommendation to intentionally > replay early data. Given that I expect that a deployment that enables > 0-RTT will tolerate some amount of side-effects globally, and that > excessive 0-RTT will trigger DoS measures, all you are doing is > removing some of the safety margin those services operate with Can I break this into two parts then? First, do you agree that it would be legitimate for a client, or an implementation (library), to deliberately replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a safety mechanism, to enforce and audit the server's and application's ability to handle the challenges of replay-ability correctly. At a bare minimum I want to be free to include this in our implementation of TLS, and in the clients that we use. I think there's value in explicitly documenting this, and that the problem is squarely on the server side if it is not replay-even-within-time-window-tolerant. Frankly: I want to be able to point to the spec and it be clear whose fault it is. Now second, consider a web service API that exists today and is using TLS. Many such APIs depend entirely on TLS for all anti-replay protection (though for the record, the SigV4 authentication mechanism we use at AWS includes its own anti-replay measure). When TLS1.3 comes along it is *very* tempting for providers to turn it on and use it for those APIs. Everyone always wants everything to be faster, and it won't be a huge code change. The problems of replay attacks could be dismissed as unlikely and left unaddressed, as security issues often are. So through a very predictable set of circumstances, I think those calls will be left vulnerable to replay issues and TLS1.3 will absolutely degrade security in these cases. What I'm suggesting is that we RECOMMEND a systematic defense: clients and/or implementations should intentionally generate duplicate data, so that the problem *has* to be addressed at least in some measure by providers. I far prefer that they be forced to encounter a low grade of errors early in their testing than to leave a large hole looming for users to fall into. This style of "Always always test the attack case in production" is also just a good practice that keeps anti-bodies strong. Thanks for reading and the feedback. On 24 November 2016 at 04:47, Colm MacCárthaigh wrote: > > > > I've submitted a PR with an expanded warning on the dangers of 0-RTT data > > for implementors: > > > > https://github.com/tlswg/tls13-spec/pull/776/files > > > > The text is there, and the TLDR summary is basically that time-based > > defenses aren't sufficient to mitigate idempotency bugs, so applications > > need to be aware of the sharp edges and have a plan. For clarity, I've > > outlined three example security issues that could arise due to realistic > and > > straightforward, but naive, use of 0-RTT. There's been some light > discussion > > of each in person and on the list. > > > > In the PR I'm "MUST"ing that applications need to include /some/ > mitigation > > for issues of this class (or else they are obviously insecure). In my > > experience this class of issue is so pernicious, and easy to overlook, > that > > I'm also "RECOMMEND"ing that applications using Zero-RTT data > > *intentionally* replay 0-RTT data non-deterministically, so as to keep > > themselves honest. > > > > At a bare minimum I think it would be good to make clear that clients and > > implementations MAY intentionally replay 0-RTT data; to keep servers on > > their toes. For example a browser could infrequently tack on a dummy > > connection with repeated 0-RTT data, or an implementation could > periodically > > spoof a 0-RTT section to the application. That should never be > considered a > > bug. but a feature. (And to be clear: I want to do this in our > > implementation). > > > > > > -- > > Colm > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > -- Colm ___ TLS mailing list TLS@ietf.org https:
Re: [TLS] Additional warnings on 0-RTT data
This seems like too much text to me. Maybe some people would appreciate the reminder that replay might cause side-effects to be triggered multiple times, or that side effects are just effects and those might also be observable. But I think that those reminders could be provided far more succinctly. The bit that concerns me most is the recommendation to intentionally replay early data. Given that I expect that a deployment that enables 0-RTT will tolerate some amount of side-effects globally, and that excessive 0-RTT will trigger DoS measures, all you are doing is removing some of the safety margin those services operate with. On 24 November 2016 at 04:47, Colm MacCárthaigh wrote: > > I've submitted a PR with an expanded warning on the dangers of 0-RTT data > for implementors: > > https://github.com/tlswg/tls13-spec/pull/776/files > > The text is there, and the TLDR summary is basically that time-based > defenses aren't sufficient to mitigate idempotency bugs, so applications > need to be aware of the sharp edges and have a plan. For clarity, I've > outlined three example security issues that could arise due to realistic and > straightforward, but naive, use of 0-RTT. There's been some light discussion > of each in person and on the list. > > In the PR I'm "MUST"ing that applications need to include /some/ mitigation > for issues of this class (or else they are obviously insecure). In my > experience this class of issue is so pernicious, and easy to overlook, that > I'm also "RECOMMEND"ing that applications using Zero-RTT data > *intentionally* replay 0-RTT data non-deterministically, so as to keep > themselves honest. > > At a bare minimum I think it would be good to make clear that clients and > implementations MAY intentionally replay 0-RTT data; to keep servers on > their toes. For example a browser could infrequently tack on a dummy > connection with repeated 0-RTT data, or an implementation could periodically > spoof a 0-RTT section to the application. That should never be considered a > bug. but a feature. (And to be clear: I want to do this in our > implementation). > > > -- > 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
[TLS] Additional warnings on 0-RTT data
I've submitted a PR with an expanded warning on the dangers of 0-RTT data for implementors: https://github.com/tlswg/tls13-spec/pull/776/files The text is there, and the TLDR summary is basically that time-based defenses aren't sufficient to mitigate idempotency bugs, so applications need to be aware of the sharp edges and have a plan. For clarity, I've outlined three example security issues that could arise due to realistic and straightforward, but naive, use of 0-RTT. There's been some light discussion of each in person and on the list. In the PR I'm "MUST"ing that applications need to include /some/ mitigation for issues of this class (or else they are obviously insecure). In my experience this class of issue is so pernicious, and easy to overlook, that I'm also "RECOMMEND"ing that applications using Zero-RTT data *intentionally* replay 0-RTT data non-deterministically, so as to keep themselves honest. At a bare minimum I think it would be good to make clear that clients and implementations MAY intentionally replay 0-RTT data; to keep servers on their toes. For example a browser could infrequently tack on a dummy connection with repeated 0-RTT data, or an implementation could periodically spoof a 0-RTT section to the application. That should never be considered a bug. but a feature. (And to be clear: I want to do this in our implementation). -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
