"ech-reject" test case and expected number of connections

[cjpatton]

We will soon want to add a test case for exercising the rejection codepath for ECH. In this setting, the client offers the ECH extension encrypted using a configuration the server doesn't recognize. In this case, the server terminates the connection with a fallback certificate --- the "client-facing" certificate, in ECH parlance --- and transmits an acceptable ECH config in its EncryptedExtensions message. The client is then expected to abort the connection with an "ech_required" alert and retry the connection with the new configuration.

This test case raises questions that we haven't fully addressed.

1. Currently, the boringssl and cloudflare-go servers quit after one connection attempt. On the other hand, rustls and nss (Add NSS endpoints for ECH interop #25) stay open after the first connection is torn down. Is it desirable to have the server quit after some number of connection attempts, perhaps a number specified by the test case?
2. Handling more than one connection adds a bit of complexity, especially if we decide to inspect the protocol transcript to determine whether a given test succeeded (as in Added basic PCAP capture and validation functionality. #24). Perhaps we should decide that the scope of each test case is a single run of the protocol? This would reasonable for the ECH rejection test case, since checking that rejection worked properly amounts to checking that the client aborted with the proper alert.

[cjpatton]

FWIW, my preference would be to quit after one connection attempt. This avoids the need to manage complexity we don't need right now.

[chris-wood]

FWIW, my preference would be to quit after one connection attempt. This avoids the need to manage complexity we don't need right now.

I concur. I think we can adequately test this feature with only a single connection. (Check for the alert, as you suggest, and check that the retry config is sent.) If we need to handle more than one connection for other use cases, we can revisit this in the future.

[cjpatton]

In that spirit, we have the following TODOs:

1. Modify the nss and rustls endpoints so that the sever quits after one handshake attempt.
2. Create "ech-reject" test.

I'll work on PRs for these this week.

[cjpatton]

This is done!