Re: [Ohai] DoubleCheck and CONNECT-UDP

[Tommy Pauly <[e-mail]>]

> On Jul 27, 2022, at 3:07 PM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> 
> 
> On Wed, Jul 27, 2022 at 2:25 PM Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>> Trying to lock people into using CONNECT-UDP to an HTTP/3 server in order for key consistency to work seems to be a “not good” state to end in. Maybe better than locking in CONNECT, but locking in any particular protocol or version seems quite limiting.
> 
> As a formal matter, I think this is essentially unavoidable in any situation where proxies are in use.  For example, in OHAI, the Relay and Gateway must both support a common HTTP version.  In practice, this likely means that (general-purpose, open) Relays and Gateways will have to support HTTP/1.1 as a de facto baseline.

There needs to be at least one HTTP version that the relay can use to speak to the gateway, yes. However, I certainly don’t see any reason why these would need to use HTTP/1.1. Relays can be picky about what gateways they allow — and I’d certainly advocate that any sensible implementation SHOULD NOT allow talking to any gateway that doesn’t at least support HTTP/2.

> 
>> I don’t think that it follows that if we don’t have CONNECT-UDP, the clients would directly fetch the key config from your proposed SDH resource.
>> 
>> To perform double checking, I think it just matters that we have one check that uses a TLS-authenticated connection to the authority for the key config, and one other check that uses a cached version on a TLS-authenticated connection to another entity that is not the authority for the key config; AND that these checks are done in such a way that the TLS-authenticated connection to the config authority does not get to track or identify the user.
> 
> I think that's an accurate description of the requirements, but I don't think documenting the requirements is sufficient.  If we don't standardize the proxy/relay protocols and their configuration, that essentially leaves the users locked into a single relay service implementation.  I don't believe that users should have to use the relay service operated by, say, their handset manufacturer or browser vendor.

I agree that users don’t need to be limited to the relay service provided by a specific manufacturer. But they do need to use protocols that their client implementation is willing to support.

If the requirement is that a client needs to access the resource that is authoritative for the OHTTP key configuration, it should be free to access that using any secure proxy protocol over which it can run a TLS connection to the key configuration resource, and it can use normal ALPN selection to know which HTTP version to use to the key configuration resource.

> 
>> What method you use to proxy a connection is entirely up to the client’s favorite proxying method, I think. Let’s not try to drag specific transports into this.
> 
> We can let the market decide the HTTP version, but I do think we should specify how the transport proxy is configured.  Otherwise it becomes very difficult for there to be multiple interoperable implementations of the relay service.

For the reasons above, I strongly disagree. We have ALPN and other ways to know what version is supported. There’s a reason we use HTTP and TLS here — we can run secure HTTP connections and let the version evolve.

Tommy

> 
>> Thanks,
>> Tommy
>> 
>> > On Jul 26, 2022, at 10:57 PM, Ben Schwartz <bemasc=[e-mail] <mailto:[e-mail]>> wrote:
>> > 
>> > 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
>> > -- 
>> > Ohai mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/ohai
>>