Re: [Ohai] DoubleCheck and CONNECT-UDP

[Ben Schwartz <[e-mail]>]

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
>