No way to know if a client is about to attempt 0-RTT

[espadolini]

The Used0RTT flag in the quic.ConnectionState returned by (quic.EarlyConnection).ConnectionState doesn't seem to be populated immediately after (*quic.Transport).DialEarly returns, unlike what the example at https://quic-go.net/docs/quic/client/#0-rtt shows.

I think it might be because the used0rtt atomic flag in internal/handshake.cryptoSetup (which ultimately feeds the flag returned to user code) is populated asynchronously by events read from the crypto/tls.QUICConn (as a consequence of golang/go#60107 perhaps?) so the caller of DialEarly can't ever know if the connection is about to try to use 0-RTT data, even though that's a decision taken entirely locally.

It would be nice if there was a way to know for sure, or at least err on the side of a false positive reading rather than a false negative, but if that's impossible and/or unadvisable to do then the docs should at least get fixed. As is, it's even possible for developers using the library to think that the data they're sending is not in danger of being replayed, which is a pretty big problem.

[marten-seemann]

If you're using DialEarly, you're asking quic-go to use 0-RTT whenever possible. If you don't want that, use Dial (which is totally fair, not every application benefits from 0-RTT).

If you still want to use 0-RTT for some, but not for other data, you can wait for handshake completion by blocking on the Connection.HandshakeComplete() channel. This channel is closed when the handshake completes, and from then on all data is sent in 1-RTT.

The Used0RTT flag on the ConnectionState tells you if the server accepted 0-RTT data.

Does that make sense?

[espadolini]

That makes perfect sense and that's how I'm using it, but the example in the docs is still misleading. 😅

[marten-seemann]

How does this sound? quic-go/docs#77