This PR describes the fallback mechanism. In short, it works like follows:
Client sends QUIC-AH Initial packet.
A server failing to process the Initial sends VN specifying v1.
Client sends V1 Initial containing CH with empty "encrypted_server_name" extension.
Server either sends the ESNI record, or the lack of, in the way specified by ESNI.
Client reattempts to create a connection.
The thing here is that we essentially need a non-authenticated ESNI handshake for obtaining the correct ESNI key (see step 3). At the moment, step 3 uses an empty "encrypted_server_name" extension because the purpose here is to purely obtain the correct ESNI record (or the lack of), but we can send an ordinary ESNI extension here too.
Then, the question that become apparent is: should we define a mechanism to just run ESNI+version greasing (#13), and make "authenticated handshake" an optional feature?
Now that https://github.com/tlswg/draft-ietf-tls-esni/pull/124 has been merged, QUIC-AH needs to provide a way to correct the ESNI Resource Record when the record possessed by the endpoints become out-of-sync.
This PR describes the fallback mechanism. In short, it works like follows:
The thing here is that we essentially need a non-authenticated ESNI handshake for obtaining the correct ESNI key (see step 3). At the moment, step 3 uses an empty "encrypted_server_name" extension because the purpose here is to purely obtain the correct ESNI record (or the lack of), but we can send an ordinary ESNI extension here too.
Then, the question that become apparent is: should we define a mechanism to just run ESNI+version greasing (#13), and make "authenticated handshake" an optional feature?