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 <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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
