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 > >
- [Ohai] DoubleCheck and CONNECT-UDP Ben Schwartz
- Re: [Ohai] DoubleCheck and CONNECT-UDP Tommy Pauly
- Re: [Ohai] DoubleCheck and CONNECT-UDP Ben Schwartz
- Re: [Ohai] DoubleCheck and CONNECT-UDP Matthew Finkel
- Re: [Ohai] DoubleCheck and CONNECT-UDP Tommy Pauly
- Re: [Ohai] DoubleCheck and CONNECT-UDP Ben Schwartz
- Re: [Ohai] DoubleCheck and CONNECT-UDP Ben Schwartz
- Re: [Ohai] DoubleCheck and CONNECT-UDP Tommy Pauly
- Re: [Ohai] DoubleCheck and CONNECT-UDP Matthew Finkel
- Re: [Ohai] DoubleCheck and CONNECT-UDP Christopher Wood
- Re: [Ohai] DoubleCheck and CONNECT-UDP Eric Orth
- Re: [Ohai] DoubleCheck and CONNECT-UDP Christopher Wood
- Re: [Ohai] DoubleCheck and CONNECT-UDP Ben Schwartz
- Re: [Ohai] DoubleCheck and CONNECT-UDP Christopher Wood