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
