How can we test disallowed states/behaviors for QUIC?

[briansmith]

How can we test the QUIC API, especially for cases where the peer is doing something wrong/bad?

We use BoringSSL's BoGo test framework to test many aspects of Rustls. In particular, buggy/malicious behavior pretty much is tested exclusively via BoGo since it's the only implementation of TLS we have that allows us to (intentionally) do the wrong thing.

I looked into how Bogo tests QUIC. BoringSSL apparently implements an API very similar to the one that Rustls implements. One difference is that it requires the QUIC implementation to do the actual record encryption/decryption, whereas Rustls encapsulates the encryption/decryption. Thus the Bogo "mock_quic_transport.{go,c,h}" used in its QUIC tests, which doesn't even encrypt anything, seems impractical to implement on top of Rustls's public QUIC API.

It seems like if we wanted to adapt the Bogo tests for QUIC to work for Rustls, we'd need to implement a mock "real" QUIC transport that encrypts/decrypts. Perhaps BoringSSL people would help us maintain that if we were to contribute it?

Or, if Bogo is a nonstarter then what is the alternative?

[Ralith]

One difference is that it requires the QUIC implementation to do the actual record encryption/decryption, whereas Rustls encapsulates the encryption/decryption.

This is a bit of an oversimplification. Rustls implements encryption primitives for QUIC, but they are decoupled from the TLS state machine; QuicExt::read_hs and write_hs operate in terms of plaintext, and are the interfaces in need of better testing. This is very natural, since the TLS handshake messages are framed by QUIC before encryption. If I understand you correctly, this is very similar to BoringSSL, so perhaps little/no work is necessary?

[briansmith]

This is a bit of an oversimplification. Rustls implements encryption primitives for QUIC, but they are decoupled from the TLS state machine; QuicExt::read_hs and write_hs operate in terms of plaintext, and are the interfaces in need of better testing.

Good point.

This is very natural, since the TLS handshake messages are framed by QUIC before encryption. If I understand you correctly, this is very similar to BoringSSL, so perhaps little/no work is necessary?

The Bogo mock transport protocol is documented near the top of mock_quic_transport.go, here: https://github.com/google/boringssl/blob/master/ssl/test/runner/mock_quic_transport.go#L48-L71. So maybe indeed we "just" need to replicate in Rust what is done in mock_quic_transport.{h,cc} in BoringSSL.