> To me, the argument against this comes down to this: The 0RTT data has > different security properties than the post-handshake data, and TLS > implementations should not hide that difference from applications. This is true, and early on there seemed to be general agreement that 0-RTT data would require explicit opt-in from the caller, e.g. via new API surface.
> Once the initial SSL_write_early_data() call has completed successfully the > client may interleave calls to SSL_read_ex(3) and SSL_read(3) with calls to > SSL_write_early_data() as required. I'm curious why the client does not have to call SSL_read_early_data instead of the normal SSL_read in this case. Cheers, Andrei _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
