On Tue, Jun 13, 2017 at 2:54 PM, 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 also agree here. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
