On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > The current text says: > > 0-RTT data has very different security properties from data > transmitted after a completed handshake: it can be replayed. > Implementations SHOULD provide different functions for reading and > writing 0-RTT data and data transmitted after the handshake, and > SHOULD NOT automatically resend 0-RTT data if it is rejected by the > server. > > I think the second piece of guidance (about automatic re-send) is still > good but it seems like implementations are mostly converging on a single > API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have > a single API and OpenSSL's use of two APIs is an outlier. I don't think > it's helpful to have a SHOULD that a lot of people violate, especially when > this also indicates we don't have consensus on this SHOULD. > > I propose we remove this recommendation in favor of one which simply says > that implementations should need applications to opt-in to 0-RTT. That > would allow implementations to have either API.
I think it is VERY bad idea for TLS client library to do 0-RTT without application explicitly opting in to that (e.g., via setting a special setting, or using API call sequences that didn't work at all for n-RTT). Consider for example that: - The application starts by sending a POST request. - The application starts by sending a GET to confidential URL. Both cases lead to things possibly going very badly wrong if TLS library silently does 0-RTT. And both are kind of requests that might be written before TLS connection is fuly up. And if ALPN is included, there is always a possibility that the initial guess on protocol was wrong, and the data can't just be autoretransmitted, but TLS stack has to ask the application to roll back the state. The server side does not have as obvious failure modes if 0-RTT is enabled without application knowledge, but that does not mean such failure modes are not out there. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
