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. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
