Re: FYI: Oblivious HTTP
Ben Schwartz <bemasc@google.com> Tue, 02 February 2021 19:40 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B4C3A110F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Feb 2021 11:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.271
X-Spam-Level:
X-Spam-Status: No, score=-10.271 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjNFhrx7FKMl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Feb 2021 11:40:52 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 78EF83A1110 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 2 Feb 2021 11:40:51 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1l71V7-0005Eg-0B for ietf-http-wg-dist@listhub.w3.org; Tue, 02 Feb 2021 19:38:13 +0000
Resent-Date: Tue, 02 Feb 2021 19:38:13 +0000
Resent-Message-Id: <E1l71V7-0005Eg-0B@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1l71V4-0005Du-QT for ietf-http-wg@listhub.w3.org; Tue, 02 Feb 2021 19:38:10 +0000
Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1l71V2-0006S6-LX for ietf-http-wg@w3.org; Tue, 02 Feb 2021 19:38:10 +0000
Received: by mail-io1-xd2c.google.com with SMTP id x21so22607222iog.10 for <ietf-http-wg@w3.org>; Tue, 02 Feb 2021 11:38:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PvvTZe3MvSIMqKyesklGud8iaUdbsagTqEUW6FkFku8=; b=XOXgpHmdfdTaf0YQHg2SN/uYWQAUqwKTp1FH0BXkxZQxufrME5bwLU4E6pKrtuJXdj 7O+Q4F+KPu19SqzfJzEYcws/HZWzNnrtLrfPvgz67yEqpe/Pf81STfJwKkisXYod10f/ EzrP83rPr9WGulCE01TJl4FLcHF6GGtKJQZsoyBVnEw69jGs2CcMW5J+s5sK7NrZuglb SkxMqCVkIBqx0MFnQUY2BJpxaWnSulNXClIqR3veaAQuA016GMe7OuGISTAhhYQctbfo B/t9nAk7qa7OLLMvX59gt0J2OSlrQPr+uiEyEz6rzUR1U+M3n0VtdrrNYU2nRby88+1S CksQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PvvTZe3MvSIMqKyesklGud8iaUdbsagTqEUW6FkFku8=; b=YEH/WCBP5Pk/oBGJWwPbQbOSCz3CN+4UZlb7BhiiI0wDdWVMt2Cb3uYEcYBF9Um9DI 4B1AR3k4IyjlbssjNKJdsZ0bpWReAiTLSOMdNKtczkhcB6cxA+NgGm2s8gF3e13w7UV6 y/nj47938TfyJ9+tJMm0r40xhr2wdhkJQvdfBiuoQlV1+W+TdY4Z3Ltm3OB1QwpSADir vRv640alM6jqKcdxORMROcf9tuAcy/BE2Dhe4xdSiNqLhPIPpyMtkjp8xOcmnig1COB4 nCW/pqhKv9oSaJBwyexFSP2l4kQ/SmnV0ApF/oBeyZT1b+xyGTK9TnuhynaTSTn6+r3r frew==
X-Gm-Message-State: AOAM532fNnPa4L6TghN/A8InrSkEido5lI4WGlHbTyqoqG0awygKMsQE zyM9VaEzibnMTwp19LGWrJupoI9q/nxtuTcBQA+BVHFowCA=
X-Google-Smtp-Source: ABdhPJys7QkTPMoGDI0THvA9ZOw7ozGBFuLYtQCRJWpR1MgEQR/9gEb6LsSz4u6W5+fcGS2VopKP5d50KO09reQVFAE=
X-Received: by 2002:a02:5148:: with SMTP id s69mr22447999jaa.8.1612294677522; Tue, 02 Feb 2021 11:37:57 -0800 (PST)
MIME-Version: 1.0
References: <ef91fafb-1586-4076-baa9-033326162eb1@www.fastmail.com> <776DC690-336A-4843-8EA1-DD5D426A0DD6@gbiv.com> <8bf39ffc-e6f8-4f0f-af2d-20e8eed154b9@www.fastmail.com> <CAF8qwaCdK6zodL5QGmMSM4U80NdSiZ+KZ16-u2_SypiEo62Ocg@mail.gmail.com> <0709f82d-150e-4423-8994-5a2549475ef4@www.fastmail.com>
In-Reply-To: <0709f82d-150e-4423-8994-5a2549475ef4@www.fastmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 02 Feb 2021 14:37:45 -0500
Message-ID: <CAHbrMsD7dKVRicZPaO25Rk3xOo_g6jP0_moGq0J3KJxfZ0wJhQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000008c3a7005ba5f9b9a"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d2c; envelope-from=bemasc@google.com; helo=mail-io1-xd2c.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=bemasc@google.com domain=google.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1l71V2-0006S6-LX 355f889239d8601296019724b05f10ec
X-Original-To: ietf-http-wg@w3.org
Subject: Re: FYI: Oblivious HTTP
Archived-At: <https://www.w3.org/mid/CAHbrMsD7dKVRicZPaO25Rk3xOo_g6jP0_moGq0J3KJxfZ0wJhQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38443
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
The DNS use case is clear enough to me. For telemetry, the utility seems much lower. Telemetry is (by definition?) not user-visible, so it's typically not latency-sensitive. Spending one or two RTTs for a standard TLS connection will not substantially impair the utility of the telemetry. Telemetry also typically doesn't require a reply from the server. There might be a telemetry-oriented variation on this design that uses a one-way flow to enable better privacy and efficiency (e.g. batching of uploads). On Sun, Jan 31, 2021 at 7:30 PM Martin Thomson <mt@lowentropy.net> wrote: > Thanks David, these are all good points to capture. I've flagged you on > the issues I've created in response to these; though it will take a little > bit of work to get this all written down. > > For those following along at home: > https://github.com/unicorn-wg/oblivious-http/issues > > On Sat, Jan 30, 2021, at 12:08, David Benjamin wrote: > > On Thu, Jan 28, 2021 at 7:23 PM Martin Thomson <mt@lowentropy.net> > wrote: > > > I think that it might be best to respond with a little more context on > what I believe the potential application of oblivious HTTP would be. The > draft doesn't really go into that, because that isn't really a good place > to capture these sorts of things. > > > > > > Just to set this aside, I don't see this as building toward > replicating something like Tor. There are obvious parallels, but the two > approaches have very different assumptions about trust and the incentives > of various actors. Tor, as a system, is also far more complex and > ambitious. So, by all means look for parallels in Tor, but understand that > this has very different models for both the threats it considers and the > environment it might be deployed in. > > > > > > The other thing that I think is important to understand is that - at > least from my perspective - the goal is not to carry any significant > proportion of HTTP requests. For instance, I don't see this being used for > web browsing. If we're willing to echo cookies, then you can safely assume > that we won't be making those requests oblivious. And many other cases > benefit from being able to establish some sort of continuity, if only to > deal with denial of service risks. Each application would have to be > assessed on its own. > > > > > > The things that we're talking about using this are those cases where > we have identified a privacy risk associated with having a server being > able to link requests. The original case in research was DNS queries, > where it has been shown that building profiles of users based on their DNS > activity has poor privacy properties. At Mozilla, we're also considering > this style of approach in other places that browsers make requests with > information that might be sensitive, like telemetry reporting. > > > > > > There are non-trivial costs associated with setting this up. As a > proxy needs to be run by a separate entity, but they don't see any direct > benefit from the service they provide, you have to arrange for their costs > to be met somehow. You need to do so in a way that the server can ensure > that the proxy is not enabling DoS attacks, while also retaining sufficient > independence that clients can trust the proxy. This is harder as the use > cases become more general, but we believe that this can be arranged for > certain specific cases. > > > > > > Does the explanation about applicability help? I realize now that I > shouldn't have left this up to inference, and the draft should probably at > least address the point directly, so I'll make sure that the next version > does something about that. > > > > I agree the draft should talk about this. I initially read it as > > intending a general replacement for proxying strategies, which seemed > > odd. As you note, in more stateful contexts like web browsing, the > > correlation boundaries are so much larger than a request that this > > probably doesn't buy much over simply partitioning connection pools. > > Whereas I could see applications with more standalone requests wanting > > different tradeoffs. > > > > One comment on the privacy properties here: the requests are only as > > uncorrelated as the key configurations used by the client. In the > > online HTTPS fetch model described here, if each client independently > > fetches, the server could maintain many configs and serve a different > > one each time. I assume that the client will cache the key > > configuration (otherwise it needs a new fetch per request, at which > > point it may as well just tunnel HTTPS), which means clients can be > > identified, or partially identified by their keys. This is helped a bit > > by the small keyID size: the server gets 8 bits plus a couple more from > > algorithm selections, and then the rest must come from trial > > decryption. But how well this mitigates it depends on volume and > > whether this could be combined with information in the requests > > themselves. (E.g. telemetry reports may reveal platform information or > > rough performance characteristics.) That's probably worth some text, > > both on the privacy implications of the suggested configuration model, > > and on privacy implications of configuration models in general. > > > > Alternatively, the proxy could cache and serve the key configuration. > > Then everyone behind the same proxy uses the same config. Though you'd > > then need some kind of offline authentication on the config, such as > > SXGs. > > > > I think the draft should also discuss the security implications a bit > > more, since it's replacing the guarantees you'd otherwise get from > > proxying HTTPS. Some things that came to mind: > > > > - Related to all the online vs offline signature excitement, the client > > probably needs to enforce a time bound on key configurations, in order > > to contain the effects of a temporary compromise. > > > > - Like TLS 1.3 0-RTT, encapsulated requests don't have replay > > protections and lack forward secrecy. This shouldn't be used where > > replay protection matters, and key configurations should be rotated > > frequently. > > > > - Unlike TLS 1.3 0-RTT, encapsulated responses also lack forward > > secrecy. (If it's an issue, I suppose you could fix this by doing a > > second HPKE in the other direction and binding the two together.) > > > > David > >
- FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Amos Jeffries
- Re: FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Toerless Eckert
- Re: FYI: Oblivious HTTP Roy T. Fielding
- Re: FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Poul-Henning Kamp
- Re: FYI: Oblivious HTTP Greg Wilkins
- Re: FYI: Oblivious HTTP Toerless Eckert
- Re: FYI: Oblivious HTTP Roy T. Fielding
- Re: FYI: Oblivious HTTP David Benjamin
- Re: FYI: Oblivious HTTP Soni L.
- Re: FYI: Oblivious HTTP Eric Rescorla
- Re: FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Martin Thomson
- Re: FYI: Oblivious HTTP Ben Schwartz
- Re: FYI: Oblivious HTTP Martin Thomson