Privacy difficulties in Blind Caching and OOB encoding

Jeffrey Yasskin <jyasskin@google.com> Thu, 03 August 2017 19:00 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 D6A19131BBF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Aug 2017 12:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.502
X-Spam-Level:
X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 hySlOiGkRYqJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Aug 2017 12:00:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (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 7A8A512F274 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 3 Aug 2017 12:00:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ddLI1-0001TR-N3 for ietf-http-wg-dist@listhub.w3.org; Thu, 03 Aug 2017 18:56:09 +0000
Resent-Date: Thu, 03 Aug 2017 18:56:09 +0000
Resent-Message-Id: <E1ddLI1-0001TR-N3@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <jyasskin@google.com>) id 1ddLHr-0001SK-EC for ietf-http-wg@listhub.w3.org; Thu, 03 Aug 2017 18:55:59 +0000
Received: from mail-wm0-f50.google.com ([74.125.82.50]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <jyasskin@google.com>) id 1ddLHp-0002h0-UN for ietf-http-wg@w3.org; Thu, 03 Aug 2017 18:55:59 +0000
Received: by mail-wm0-f50.google.com with SMTP id m85so2836421wma.1 for <ietf-http-wg@w3.org>; Thu, 03 Aug 2017 11:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Dy1OTKiKwb3sT0KeHShnCbpDsooiGVegnKWG/fPocj4=; b=bRAnF9mDmfQvODVEP4SquXJTKSfhZLDsXYSsx3kUZcQlAzuGdZdBqjdo/yakZOyaY3 g0fWdToex6ixnsnbXrIM40BCBI+/5FXD0C0HK2e9cxsYRls8WlmwyqcuqWsK0XwIfeB4 EzwTrhWiCFQoQjxXsxeDmH1pxkmcCri4js3TqwXdZd3dyMdK0Rh6/w4NwDkdLk9+X+qL xWYa2DMvW/35e9supvC1rSmeO0JM7emyjomuQxTFLWw6mI1qSQmrvnS/iwEoCz77G3IE fulV499uIntty6349ggbz6wzmHcE/QY5f9NSJdbcP7bMjChvHkpPI9h+Lh7MxR5qmIFg 3QZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Dy1OTKiKwb3sT0KeHShnCbpDsooiGVegnKWG/fPocj4=; b=UvrLK9W5UMVJfr+BW/2UKB9vBwOwSqzQ+DKBrAcBTyPFNDkgNq2EnEKGzdS80LU+bu TS7DqN3EPmZ6VyQXOryQNnFpxZHruuKPZcG6cChWIwlBlxWGLOL7mcmi63xaci5b/ZHn RvHIDsfwE4ukZF0Pph8TyglCAt3Z61gIx2lmI+s3QG3GNX70IRM6EObP+LMhLqNh1wkl 25DRIJoKger7O7MTvUB1bJ5upVmPWvkJEFdZ33U1wBBXkc916jy51TvBW7VKJhjXPn4V Qdeo1S6BtHmBpCMepuNmrjXhANcVQemFnwKc3t0qA6wPXgDpZFwmzIfsMcKmD4DfvDFh TsOA==
X-Gm-Message-State: AHYfb5jl9mUlGfUQ7QRxZW67bO3nrDxR/NwCLvQGoplVtP0D/47tmLz6 mKBe+3eJ8IuRIsqDl7W/9eiwHT1ES3mngDOhiA==
X-Received: by 10.28.52.142 with SMTP id b136mr217418wma.48.1501786535070; Thu, 03 Aug 2017 11:55:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.216.144 with HTTP; Thu, 3 Aug 2017 11:55:14 -0700 (PDT)
From: Jeffrey Yasskin <jyasskin@google.com>
Date: Thu, 03 Aug 2017 11:55:14 -0700
Message-ID: <CANh-dXmCDMSpzoUzxZudaTG_MTcR9vwSv4qPknjeRfD01J=Zeg@mail.gmail.com>
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.50; envelope-from=jyasskin@google.com; helo=mail-wm0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=2.439, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ddLHp-0002h0-UN cd8eba946ca16b7165e2068951660485
X-Original-To: ietf-http-wg@w3.org
Subject: Privacy difficulties in Blind Caching and OOB encoding
Archived-At: <http://www.w3.org/mid/CANh-dXmCDMSpzoUzxZudaTG_MTcR9vwSv4qPknjeRfD01J=Zeg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/34229
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I was reading draft-thomson-http-bc-01,
draft-reschke-http-oob-encoding-12, and some of their dependencies,
and I'm having trouble finding the plan for getting caches to actually
speed things up while at the same time preventing caches from learning
important information about the content their clients are
transferring.

The core idea of the out-of-band encoding, as described in the drafts
and [ERICSSON], is that the origin server can delegate content
transmission to an edge cache to which the client has a faster
connection than it has to the origin.

When we account for the origin->cache transmission, this should be
slower for the first client and significantly faster for all
subsequent clients. That is, more than one client MUST be able to use
the same resource bytes, which means, if they're encrypted
([RFC8188]), that all clients must get the same key to decrypt them.
That has several implications:

1) For public resources, the cache can trivially figure out what
content clients are retrieving, by pretending to be a client itself to
get the decryption keys. This is an important decrease in privacy
compared to TLS, but I don't see it mentioned in [BC]. It seems to
conflict with calling the caching "blind".

2) For secret resources, the cache may not be able to authenticate
sufficiently to retrieve decryption keys, but it can still trivially
figure out that multiple clients are retrieving the same resource.
This metadata is another decrease in privacy compared to TLS.

3) [OOB] and [SCD] both mention a forgery risk and sketch some
mitigations around [SIG] and [MICE], but that's less relevant for this
email.

Have I missed anything in the documents or the design that hides more
information from the caches?

Thanks,
Jeffrey

[BC] https://tools.ietf.org/html/draft-thomson-http-bc-01
[OOB] https://tools.ietf.org/html/draft-reschke-http-oob-encoding-12
[SCD] https://tools.ietf.org/html/draft-thomson-http-scd-02
[ERICSSON] https://www.ericsson.com/en/publications/ericsson-technology-review/archive/2016/blind-cache-a-solution-to-content-delivery-challenges-in-an-all-encrypted-web
[RFC8188] https://tools.ietf.org/html/rfc8188
[SIG] https://tools.ietf.org/html/draft-thomson-http-content-signature-00
[MICE] https://tools.ietf.org/html/draft-thomson-http-mice-02