I think the discussion about not understanding the implications of replayability is not correct. We are already in the situation where client data is replayable. For example if a mobile app encounters an HTTP error, it will probably retry the request throwing caution to the wind about replayability. Many popular HTTP libraries already do this very actively. In this scenario, even TLS1.2 replayability gurantees fall apart. At Facebook, we have several popular mobile applications and have plenty of experience dealing with retries.
Like Kyle mentioned the thing that 0-RTT adds to this is infinite replayability. As mentioned in the other thread we have ways to reduce the impact of infinite replayable data for TLS, making it reasonably replay safe. Discussions of replayability in the void is impossible. There is no way TLS1.3 is going to know all the use cases for replayability. That is an application layer decision. Thus we should have proposals at the application layer as well to express these properties to the transport layer, and we have one proposal for this which we're going to submit soon to HTTP WG. For example in the case of http, an application should express to the lower layers that the request that it is sending out is retry safe and that it is taking care of it. Developers are adults too. We can prevent them from shooting themselves in the foot by providing secure OFF by default option, but completely removing the option from them expressing these application properties to the underlying transport layer seems like treating them like children. I would hate to see 0-RTT removed from the spec. This is something we at Facebook are looking forward to using and want to use immediately in browsers once it is available. Subodh ________________________________________ From: TLS [[email protected]] on behalf of Viktor Dukhovni [[email protected]] Sent: Monday, March 14, 2016 10:36 AM To: [email protected] Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <[email protected]> > wrote: > > So, can people suggest ways in which we can figure out the impact > of replayable data across all the many uses of TLS? For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes good sense. There is no need for replay protection in the absence of side-effects. Web browsers are not the only use-case for TLS. Similarly, in SMTP with STARTTLS the client's first data payload is a repeat of an EHLO command that was already sent in the clear! So one might for example send the client's EHLO as 0-RTT replayable data. Of course SMTP servers that support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely available in SSL/TLS toolkits. -- Viktor. _______________________________________________ TLS mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e= _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
