Re: [Ohai] DoubleCheck and CONNECT-UDP

Ben Schwartz <bemasc@google.com> Wed, 27 July 2022 19:08 UTC

Return-Path: <bemasc@google.com>
X-Original-To: ohai@ietfa.amsl.com
Delivered-To: ohai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BB4C157B41 for <ohai@ietfa.amsl.com>; Wed, 27 Jul 2022 12:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Level:
X-Spam-Status: No, score=-17.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Brxo7n6Wpyh for <ohai@ietfa.amsl.com>; Wed, 27 Jul 2022 12:07:59 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4355AC157B37 for <ohai@ietf.org>; Wed, 27 Jul 2022 12:07:59 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id n138so14247162iod.4 for <ohai@ietf.org>; Wed, 27 Jul 2022 12:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k5+glFSP9aCm8NutkVLy2mzbrond6fleiODPZEiHKjE=; b=JH7YALX4C+nPRdEATng6Z1iR19CEYjXa34rwcm1R643k1ehStYS14xD2ReZscM88jt 0b+jBM3mvivTy53o5zG4+kidKQOtZ4nPqCtWzPeF/87T7dFPK7NOdbrRHtLO2bUq+4Vl tZcqjFk/AWPZR2EzvEp/6eW5zBHLIGVGvoxR8dHBSFEPel5io2VvOgsQboGg2j5B3L+o pNPLkppkCqnagYM2DdXdamM8E7ihmsz0vFE3T1vAAhKua/7RpUgsXZp4KuB4g5645Vjx XY2MIl4JXsout1dEZlusZVkja/qt/4/jxWAxcTQY4r3q9C3EY1zxvkV3LIcx1WJexk77 Y2CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k5+glFSP9aCm8NutkVLy2mzbrond6fleiODPZEiHKjE=; b=7i17b9YKmhQM1se2FzqyHeCibLvCYHfCgX3+2OyDwsgRlhcu4hydthg+AAa/WvF24A 5ffYyCshKCgbaEMABlyTMoBlG/LCGyseHYAgMPd4zPoEWLe+7oBbovVVOerTYieRsFJF kq/o3G+Fc/0snHdATP/FeceGy8eWgdc4lcAO0VUeDI7Cw3LkG/qr1/Yhs6pFRuDjqrP7 GSUi12A3DvKQmWHGUo7HsN+jp5ariNm8wYVeBr//zrZIkma9pS4Dvq92Jvu67DWseEjn sme8YMAMP8ufqF3DvfRKzrUWC8pIHE/M07ne69XMU2Hwh008PXSOuF5qr+SYoQPLzHlq z0NQ==
X-Gm-Message-State: AJIora/fdIacm9n2a+v1RCovgCk+EH+xdgc79hAL8ctyw4O+LEOg2Uvb 6tpfhS+xvTcSfrLKd0B6ybrDFeyC1jwpO9HgWbCKozFrV4I=
X-Google-Smtp-Source: AGRyM1vMBGOlfCA8v4eI/tgGV0FTXySX8qOZpFkvwPnADKZ5fSdkJHn0gPBd3IaYReR3ytu6smqPtP2T6udYQC2zQL8=
X-Received: by 2002:a05:6638:2713:b0:341:4773:16f0 with SMTP id m19-20020a056638271300b00341477316f0mr9621699jav.263.1658948876948; Wed, 27 Jul 2022 12:07:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsATSEU0iqybh6vqH-Mv0egJiEhpxA8vEmJNehdE0i3adQ@mail.gmail.com> <D4A56610-9E62-4F5F-BD89-47C78E47EC34@apple.com>
In-Reply-To: <D4A56610-9E62-4F5F-BD89-47C78E47EC34@apple.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 27 Jul 2022 15:07:45 -0400
Message-ID: <CAHbrMsDVDWHsq4FZz5i+VesJ+1xRO1=uCHQt63N3bGUedt6aNA@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: ohai@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000089d9ef05e4ce22ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohai/kUj1npIWQa1gTWIqc9mFQNkoHkU>
Subject: Re: [Ohai] DoubleCheck and CONNECT-UDP
X-BeenThere: ohai@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Oblivious HTTP Application Intermediation <ohai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohai>, <mailto:ohai-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohai/>
List-Post: <mailto:ohai@ietf.org>
List-Help: <mailto:ohai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohai>, <mailto:ohai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2022 19:08:00 -0000

On Wed, Jul 27, 2022 at 2:25 PM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> 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.

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.

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.

Thanks,
> Tommy
>
> > On Jul 26, 2022, at 10:57 PM, Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org> 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
> > Ohai@ietf.org
> > https://www.ietf.org/mailman/listinfo/ohai
>
>