Re: [Ohai] DoubleCheck and CONNECT-UDP

[Christopher Wood <[e-mail]>]

Well, again, answers to all of these questions very much depend on the application and threat model. So I don’t agree with the claim that this needs to be rigid. Having “profiles” or recommendations or something like that might be a fine compromise.

Best,
Chris 

On Thu, Aug 4, 2022, at 4:18 PM, Ben Schwartz wrote:
> DoubleCheck only works if the Gateway and Relay abide by certain 
> concrete requirements, beyond the minimum required by HTTP and OHTTP.  
> For example
>
> * The Gateway (or in the draft's terms, the "Service Description Host") 
> has to handle the If-Match request header in a very specific, somewhat 
> unusual way.
> * The Relay (or some closely affiliated HTTP forward proxy) has to 
> implement HTTP caching, with an unusually strict interpretation of 
> "Cache-Control: immutable".
> * (Controversial) The Relay needs to have an affiliated 
> CONNECT/CONNECT-UDP proxy as well.
>
> If the Client, Gateway, and Relay are all managed and coordinated 
> privately (as in the current deployments I've heard about), they can 
> decide for themselves whether to meet these requirements and use this 
> strategy.  However, if we actually want open interoperability between 
> clients, gateways, and relays, then we need answers to questions like:
>
> * How is a relay identified to a client?
> * If the client stumbles across an OHTTP Gateway (e.g. 
> draft-pauly-ohai-svcb-config) for a Target that the user is trying to 
> reach obliviously, how does the client fetch the KeyConfig safely?
> * If this fetch requires functionality from the relay beyond the OHTTP 
> baseline requirements, how does the client locate and access that 
> functionality?
>
> I don't think DoubleCheck (or anything like it) should be a normative 
> requirement for OHTTP itself, but I do think we need to agree on one or 
> more "profiles" so that clients can say "I work with any relay, and can 
> reach any gateway/target, provided they comply with RFCs X, Y, and Z".
>
> Even if there are clients that want to use a Multi-Proxy fetch strategy 
> (e.g. via Tor), I think we will still need Standards-Track documents to 
> set the rules for things like KeyConfig rotation strategies.  (Can I 
> serve two KeyConfigs with overlapping cache lifetimes?  How about ten, 
> with disjoint lifetimes?  If the client encounters an inconsistency, 
> does it retry until it reaches consistency, or does it fail if the 
> inconsistency exceeds some limit?)
>
> On Thu, Aug 4, 2022 at 3:14 PM Christopher Wood <[e-mail]> wrote:
>> 
>> > On Aug 4, 2022, at 3:03 PM, Eric Orth <[e-mail]> wrote:
>> > 
>> > 
>> > On Wed, Aug 3, 2022 at 8:56 PM Christopher Wood <[e-mail]> wrote:
>> > 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.
>> > 
>> > I strongly believe we should have both.
>> > 
>> > oHTTP is mostly used for "special cases", so there's certainly lots of room for different implementations to have special needs and capabilities and only need general pattern and requirement advice.  draft-wood-key-consistency-02 is good for filling this role (but should maybe be updated a bit to also cover more generalized advice around this doublecheck as a pattern), and I want to see that draft get adopted somewhere (OHAI?).
>> > 
>> > But the requirements to do something correctly and safely following the patterns is also very tricky, as evidenced by all the thought that had to go into this draft and various discussions (both public and side) that I have seen regarding this draft since last week.  While we definitely shouldn't force it on all oHTTP implementations, I strongly believe we need at least one standardized full protocol for safely exchanging the oHTTP key, and I support this draft to fill that role.
>> 
>> That’s a reasonable position, but I don’t know what you mean by “standardized protocol” here. Let’s say the gateway exposes a resource containing its configuration for DoubleCheck. I don’t see how we need a new protocol for accessing this resource. Depending on the application requirements, one could fetch it directly from the gateway, use CONNECT through the relay, or just fetch it over Tor. 
>> 
>> What would you expect this “protocol” to say?
>> 
>> Best,
>> Chris
>> -- 
>> Ohai mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ohai
> Attachments:
> * smime.p7s