Re: [Ohai] DoubleCheck and CONNECT-UDP

[Ben Schwartz <[e-mail]>]

On Wed, Jul 27, 2022 at 5:43 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

>
>
> 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]> 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.
>

This is my prediction of how the ecosystem would evolve absent any
recommendation in the spec.  Neither Gateway nor Relay operators would feel
confident that they could disable HTTP/1.1 without breaking some
counterparts, since nothing prohibits a compliant Gateway or Relay from
being HTTP/1.1-only.  (This outcome is probably fine, since supporting
HTTP/1.1 is mostly harmless.)


> Relays can be picky about what gateways they allow
>

My focus here is on Relays that allow (authorized) users to reach any
Gateway on the internet (and similarly, Gateways that are reachable from
any Relay).  I think such "universal relays" are very natural, as a
companion service to privacy proxies that similarly allow access to
arbitrary destinations.

Limited-purpose Gateways and Relays, which only support a fixed set of
approved counterparts, are in a very different position.  If the client has
to know which Gateways are usable with the Relay, the service that provides
this information to the client might also be trusted to provide authentic,
consistent KeyConfigs.


> — and I’d certainly advocate that any sensible implementation SHOULD NOT
> allow talking to any gateway that doesn’t at least support HTTP/2.
>

We can certainly put that in draft-ietf-ohai-ohttp, but it isn't there yet!

> 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 we don't standardize what those protocols are, an independent Relay
operator can't be sure that they are compatible with DoubleCheck clients.

However, given the feedback so far, I think the most likely outcome is that
the draft will mention CONNECT and CONNECT-UDP, without mandating either,
and almost everyone will end up implementing both.  That seems like a
suboptimal outcome, but it's tolerable.

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.
>

ALPN doesn't cover TCP vs. UDP selection.

In practice, if we don't offer any recommendations regarding HTTP versions,
the ecosystem will converge on something that works.  It just might not be
the most efficient outcome.

> 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.
>

I'm not talking about the HTTP version; I'm talking about an Access Service
Description (or an equivalent standardized configuration) for the Relay.  A
standardized Relay configuration system is necessary if independent
operators are going to reasonably be able to provide clients with an
affiliated Relay/cache, transport proxy(s), and DoH server.  This standard
can potentially support multiple transport proxy protocols (e.g. CONNECT
and CONNECT-UDP), at the risk of partitioning the anonymity set due to
varying client transport support.