On Wed, Nov 23, 2016 at 3:03 PM, Martin Thomson <martin.thom...@gmail.com> 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 <c...@allcosts.net> 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://www.ietf.org/mailman/listinfo/tls
