[Ohai] DoubleCheck and CONNECT-UDP

[Ben Schwartz <[e-mail]>]

During my presentation today, I suggested that the DoubleCheck procedure
might not need CONNECT-UDP if it's acceptable for the Service Description
Host (SDH), which is presumed to be affiliated with the gateway, to learn
the pool of client IPs.  On second thought, I believe the CONNECT-UDP
tunnel is indeed necessary.

Without the CONNECT-UDP tunnel, clients would authenticate the KeyConfig by
fetching it directly from the SDH.   In this arrangement, it is often
possible for the gateway to identify the precise client IP that issued a
particular OHTTP request, due to timing correlation.  If the rate of
queries to this gateway (through this relay) is relatively low (<1 QPS),
correlation is trivial.  The gateway can constantly rotate its KeyConfig,
forcing clients to reauthenticate it before each OHTTP request.

At higher query rates, other tricks are possible, such as rotating the
KeyConfig and then slow-walking the authentication responses.  By sending
authentication responses to each client "one at a time", the SDH and
Gateway can observe the OHTTP request that follows each authentication
response.

In other words, OHTTP requests are linkable (via timing) to the
corresponding KeyConfig authentication requests, so these authentication
requests must not be linkable to anything else.  This means authentication
requests from all clients on the relay must be indistinguishable, so they
must all go through a single proxy.

Martin Thomson also mentioned the question of "CONNECT" vs. "CONNECT-UDP".
The key point here is that we are building a standard for interoperability
between Service Description Hosts and Relays (acting as transport proxies),
and they need to agree on what transport to use.  Thus, our options are:

1. Require Relays to implement CONNECT, and require Service Description
Hosts to implement HTTP/1.1 or HTTP/2.
2. Require Relays to implement CONNECT-UDP, and require Service Description
Hosts to implement HTTP/3.
3. Require Relays to implement CONNECT and CONNECT-UDP, and let Service
Description Hosts do whatever they want.

All of these options are acceptable to me, but note that whatever choice we
make is essentially permanent.  If we choose Option 1, Service Description
Hosts will have to support TCP forever, for compatibility with existing
Relays.  If we choose Option 2, the entire system can be implemented
without using TCP at all.  I think the right answer depends on whether you
believe HTTP/3 is "the future of HTTP".

--Ben Schwarz