On Thu, May 4, 2017 at 10:07 AM, Andrei Popov <andrei.po...@microsoft.com> wrote:
> IMHO what we have is a facility in TLS 1.3 that: > 1. Requires extraordinary effort on the server side to mitigate replay > (for all but the smallest deployments); > 2. Offers no way for the client to determine whether the server is > mitigating replay (before replay becomes possible); > I'm less worried about these problems. There's a nice property that the operators of large deployments tend to also be technically sophisticated. I don't think we'll have a problem implementing a single use cache, strike register, we have similar systems for other services, at higher volumes. It's a cost of being big, and that's ok. It will be possible to tell whether a service permits replays; by trying them. If the service permits them, that's a pretty clear CVE, and the usual incentives work as well as they usually do. > 3. Is trivial to enable on the client and improves connection latency; > 4. Eliminates a nonce that other protocols (used to) rely on. > > While it is true that there are cases where this facility is beneficial, > there is no doubt that it will be widely misused, in both applications and > protocols. > This doesn't need to be an anchor around the neck of the whole feature. 0-RTT is still an awesome speed benefit - if servers prevent replays, I think we have a very good balance. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
