On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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). > I agree with this. I am suggesting that a setting rather than a separate API is a reasonable approach. -Ekr > > 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
