SSL_read_early_data for 0-rtt TLSv1.3?

[shinrich]

Has anyone started thinking about what code changes we should make from the server side to support 0-RTT TLSv1.3 handshakes?

SSL_read_early_data() seems like the key function. And not surprising there are security issues here.

tatsuhiro has a PR against nghttp2 with this support and he had an endpoint running for a while for people to test against.
nghttp2/nghttp2#846

I know that the QUIC folks have been working with TLSv1.3 for a while, so they are probably already deep into considering this.

[masaori335]

The quic-latest branch is using this API for 0-RTT on QUIC, but I haven't worked on master branch yet. Because QUIC's 0-RTT is little bit different from TLSv1.3's 0-RTT.

It's good time to support this. The API and OpenSSL v1.1.1 looks stable.

This could be another topic, but for the replay attack, we should also take a look at Using Early Data in HTTP.

[masaori335]

"Using Early Data in HTTP" is published as RFC 8470.

/cc @zwoop @randall

[calavera]

I think this could be a good future improvement:

Furthermore, Cloudflare can uniquely identify connection resumption attempts, so we relay this information to the origin by adding an extra header to 0-RTT requests. This header uniquely identifies the request, so if one gets repeated, the origin will know it's a replay attack.

Here’s what the header looks like:

Cf-0rtt-Unique: 37033bcb6b42d2bcf08af3b8dbae305a

The hexadecimal value is derived from a piece of data called a PSK binder, which is unique per 0-RTT request.

Generally speaking, 0-RTT is safe for most web sites and applications. If your web application does strange things and you’re concerned about its replay safety, consider not using 0-RTT until you can be certain that there are no negative effects.

From Cloudflare's blog post: https://blog.cloudflare.com/introducing-0-rtt/

[shinrich]

Talked with @duke8253 and @jvgutierrez. I think at least phase 1 of 0-RTT is good. So closing this issue.