Re: [Ohai] DoubleCheck and CONNECT-UDP

[Christopher Wood <[e-mail]>]

On Thu, Jul 28, 2022, at 7:12 AM, Tommy Pauly wrote:
>> On Jul 27, 2022, at 7:00 PM, Ben Schwartz <bemasc=[e-mail]> wrote:
>> 
>> 
>> 
>> 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.)
>
> For a relay and gateway, HTTP/1.1 isn’t quite so harmless from a 
> resource consumption aspect. If a relay is handling millions of 
> requests, putting these onto HTTP/2 or HTTP/3 connections that can more 
> efficiently multiplex is preferable to opening up tons of parallel 
> sockets between the two boxes, or adding a lot of latency via 
> head-of-line blocking.
>
> This is the same reason that using HTTP/1.1 for DoH is a pretty bad 
> idea compared to H2 or H3.
>
> Gateways and Relays are all new things. I don’t see a reason either 
> would ever need to support HTTP/1.1. I think the ones we are using are 
> only ever using at least HTTP/2, and there would be no intention of 
> going backwards.
>
>>  
>>> 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.
>
> I’m not entirely sure — I think there will be relays that are not 
> entirely special-purpose, but they likely will need some established 
> relationship to verify the stance of a gateway. I.e., to be added to 
> the ACLs, establish any mutual authentication that is needed, etc. That 
> may be something that can be automated to a degree, or just audited.
>
>> 
>> 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 this needs to be in that draft — I think we let 
> implementations do what they need to, since there are ways to negotiate 
> version. But the base OHTTP assumes you know what you’re doing and how 
> you set up your relays and gateways. If we have new documents that talk 
> about mixing and matching deployments, that deployment guide can give 
> more advice.
>
>>>>> 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.
>
> I think the client should be able to use whatever proxying mechanism 
> its relays/proxies support, and what the config lookup resource 
> supports. The double-check mechanism shouldn’t need to rely on what the 
> proxying landscape looks like, just that there is one.
>
>> 
>>> 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.
>
> Doesn’t it? If I get ALPNs of both h2 and h3 in my SVCB records, don’t 
> I know which to use?
>
>> 
>> 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.
>
> Yes, the ecosystem will converge and continue to evolve, and I expect 
> that it will do the right thing for now, since no one should have an 
> incentive to support old versions like HTTP/1.1 for these new services.
>
>>>>> 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.
>
> This is a conversation that belongs to the larger scope of how we know 
> configuration. I think there can be reasonable baselines — that we say 
> a baseline CONNECT-like relay always supports both CONNECT and 
> CONNECT-UDP to be able to access both TCP and QUIC upstream hosts that 
> are allowed by the relay.
>
> But, overall, I don’t think that the mechanism of double-check needs to 
> care — it just says “you have some relay or proxy you’ve learned about, 
> use it in this way”. That would allow us, for example, to update and 
> have -bis relay/proxy documents without needing to rev or change the 
> document that explains that you should double check key configs.

I agree with Tommy here. I view DoubleCheck less as a “protocol” and more as a pattern. One could implement it in many ways using a myriad of transports. I tend to think we ought to simply state the requirements here and leave it at that.

Moreover, the original motivation for requiring that relays support some CONNECT variant due to timing correlation seems pretty narrow. There will undoubtedly be applications that don’t require low-latency OHTTP transactions, maybe because requests are sent on a schedule. Apple’s PCM proposal, for example, does something similar here, wherein it requires that clients first validate consistency of a server’s public key at some point in the future before initiating a transaction (uploading a report). 

Correlation based on timing is certainly a concern for some applications and some threat models, but it doesn’t apply to all. Forcing a solution for it onto everyone seems overly prescriptive. I think a better outcome would to be clear about the trade offs involved here.

Best,
Chris 

>
> Tommy
>
>> -- 
>> Ohai mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ohai
>
> -- 
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai