Re: [Ohai] DoubleCheck and CONNECT-UDP
Matthew Finkel <sysrqb@apple.com> Wed, 27 July 2022 19:39 UTC
Return-Path: <sysrqb@apple.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 DC83AC13CCD7 for <ohai@ietfa.amsl.com>; Wed, 27 Jul 2022 12:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.691
X-Spam-Level:
X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 41MXJmD2S2V8 for <ohai@ietfa.amsl.com>; Wed, 27 Jul 2022 12:39:15 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F344C15AD22 for <ohai@ietf.org>; Wed, 27 Jul 2022 12:39:15 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 26RJYt9n003465 for <ohai@ietf.org>; Wed, 27 Jul 2022 12:39:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=oMEhvxzOabnvPE0vrwM3WimAlSodoYB0htReYckmOLs=; b=Bk2kj+sPNLV/LXc6CXqGoj/xw4BVASzfo2DXvuWJZZ19+w14Y0n7spC0Wm/YZPb0Yq/W vyq31lefwVItKAw2wTl/GDAeHXRShalxKGjKp7Pc7Mhmfsq4d/ou9CKll5KGVkqVtU2g dLZ5zU/6Y2wJvWaCCyU427civHKEGg8z40pGkd9IoMu8R79B64qQJE98mWaLLQlQ2uFy tgLqY3GdPEaZWNlfgrvjP+rKHvnDPERpnNaW0oU1Brn22eYd7G1IrJt8/nQKOX3h/Jxy hWx3feAgvX06DlMXht4bmF/u7/i4ja0rzgLI8hs+t4E4L+9yqqhl4Zqv01EZXWItCRu+ 6w==
Received: from ma-mailsvcp-mta-lapp03.corp.apple.com (ma-mailsvcp-mta-lapp03.corp.apple.com [10.226.18.135]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3hgejcgnfe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <ohai@ietf.org>; Wed, 27 Jul 2022 12:39:15 -0700
Received: from ma-mailsvcp-mmp-lapp03.apple.com (ma-mailsvcp-mmp-lapp03.apple.com [17.32.222.16]) by ma-mailsvcp-mta-lapp03.corp.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RFP011IM2LEML40@ma-mailsvcp-mta-lapp03.corp.apple.com> for ohai@ietf.org; Wed, 27 Jul 2022 12:39:14 -0700 (PDT)
Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp03.apple.com by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RFP00E001Y5Y000@ma-mailsvcp-mmp-lapp03.apple.com> for ohai@ietf.org; Wed, 27 Jul 2022 12:39:14 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 5cc367d0396043b07348fad981ec8473
X-Va-E-CD: dec9f7cf13e97f8c6a934fbde3c0bc04
X-Va-R-CD: e871c40da6543cb5de056467daa24094
X-Va-CD: 0
X-Va-ID: dabc0ed2-e3d5-42c8-a458-509b0cc1db38
X-V-A:
X-V-T-CD: 5cc367d0396043b07348fad981ec8473
X-V-E-CD: dec9f7cf13e97f8c6a934fbde3c0bc04
X-V-R-CD: e871c40da6543cb5de056467daa24094
X-V-CD: 0
X-V-ID: aff91dd4-a2a0-4831-94e1-78f40ede4568
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-27_08:2022-07-27, 2022-07-27 signatures=0
Received: from smtpclient.apple (unknown [17.234.209.151]) by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RFP00NEI2LCIN00@ma-mailsvcp-mmp-lapp03.apple.com> for ohai@ietf.org; Wed, 27 Jul 2022 12:39:14 -0700 (PDT)
From: Matthew Finkel <sysrqb@apple.com>
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3729.0.22.1.1\))
Date: Wed, 27 Jul 2022 15:39:00 -0400
References: <20220727040122.bpumth5yamgmlgbb@localhost> <CAPJ=pvS3sOkttASUjcLvXBXxky=Ob903qb92c-jQii0cEKRwoA@mail.gmail.com> <CAPJ=pvTsEj6zX2Tk92jTV88mZpskTL-iHhc+6uq1CEPCPUG+iQ@mail.gmail.com> <CAPJ=pvSfCc3X4+nqwbcuNohO-Z2ZBsf6MGHAyoJjDxcpDqaxdQ@mail.gmail.com>
To: ohai@ietf.org
In-reply-to: <CAPJ=pvSfCc3X4+nqwbcuNohO-Z2ZBsf6MGHAyoJjDxcpDqaxdQ@mail.gmail.com>
Message-id: <EF9174FA-7D60-4F80-9C5F-605E2BD70FB4@apple.com>
X-Mailer: Apple Mail (2.3729.0.22.1.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-27_08:2022-07-27, 2022-07-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohai/JNGdGUMMLgt7Z2L3fr8B1bSe4xo>
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:41:58 -0000
On Tue, Jul 26, 2022 at 10:57:33PM -0400, Ben Schwartz 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. I agree, thanks for thinking through this attack and writing a concrete proposal for achieving key consistency and correctness. We should probably update the referenced informational KCCS document with some of these insights, as well. I also appreciate how this design leverages multiple discovery methods. As for feedback on the draft: 1) Is there a specific reason why this depends on the Access Service Descriptions? I see why they are useful, but they seem more like a convenience than a required dependency, is this true? 2) The concern described at the end of the introduction around not using the same update mechanism for key rotation as the one used for configuring the "Service Description" seems like a bit of a stretch. First, key rotation should not be occurring at such a high frequency that a slower (software release process) update mechanism is inadequate. Second, as mentioned in the KCCS document, we recommend specifying a "minimum validity period" for these keys such that a service can't easily partition users based on which key they know/use. While we didn't recommend any specific minimum period length, I would certainly recommend a lower-bound on the order of days (with typical rotation on the order of weeks, at a minimum). Providing more flexibility and agility opens more avenues for abuse, but I am interested in hearing any trade-offs you thought about for this, too. 3) Not directly feedback on this draft, but most obviously, the consistency guarantees are only limited to users of the same relay (I believe you mentioned this, but I can't find it now), so we may be missing "global" consistency (if the service is used via multiple/arbitrary relays). As discussed in other contexts, "global consistency" really reduces to ensuring each client request originates from a sufficiently large client anonymity set. Defining "sufficiently large" is likely context and application-specific, but it should be explicitly considered in deployments. This is related to "precondition (1)", but it is not the same. Do you have thoughts you can share on this? 4) A possible TODO: Regarding the response by a Service when the Service Description changes but a request's If-Match header identifies a previous version of the resource: Should the Service cache old versions for a certain time? Maybe something like an additional max-age length? The draft doesn't seem to specify when the Service should stop returning a success response for old resources. 5) A possible TODO: What should be the client's behavior if the response from the relay is rejected or if establishing the CONNECT-UDP tunnel fails? Fail-open? Fail-closed? Attempt check via alternative relay and/or choose different service? This could be application-specific logic, but it could be worth describing trade-offs of different behaviors in this situation. In particular, the relay is in a position to maliciously perform a denial of service during this check and it could force the client to choose a different service (possibly one that will collude with the relay). On a more nitty-note, I'm not sure how much you like the "DoubleCheck" name, but as another option we've referred to similar behavior as "multi-path verification". Thanks, Matt
- [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