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 <colm@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
>