Re: [Privacy-pass] Questions on client trust

Chelsea Komlo <chelsea.komlo@gmail.com> Tue, 14 April 2020 02:14 UTC

Return-Path: <chelsea.komlo@gmail.com>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726623A040C for <privacy-pass@ietfa.amsl.com>; Mon, 13 Apr 2020 19:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D6dmul5WLVin for <privacy-pass@ietfa.amsl.com>; Mon, 13 Apr 2020 19:14:22 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D97C3A0410 for <privacy-pass@ietf.org>; Mon, 13 Apr 2020 19:14:22 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id i10so12464986wrv.10 for <privacy-pass@ietf.org>; Mon, 13 Apr 2020 19:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KysYYhDCSjZX7JbOR3i808rBJjCPoFqzBeBjSM5WPjg=; b=shOexMgQKLNdgpQuq1URuhxoROc2dbV90XDLF+9IwGCNVMuF+IHVemyxGwNf8rgZE1 YwpA98tDoogZ0RHGbrEMlFs9slYTao8vx3hjOw2WhaA/muBYMPu5pDM30McuIpW5eyAt Wr/iRlIS2uHBxGDAMFdvm8mT5oljNNtrToPPOIcWVyIEtB15+LeDiZfFfo3sfiH/pCab s6EIHwhZR3JGvL8uvCdA9RIEW94io9hjVU/a+ucEY9qFkIJ2HQbSKmFudSd3Zz4KXlW1 jIaJ7A193reatoC7MtYxJVsOahKfnbSJQE25DEfpFuxVYJccVuTeCrT6GNIJa2IzGkve 34qw==
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=KysYYhDCSjZX7JbOR3i808rBJjCPoFqzBeBjSM5WPjg=; b=RNmQ9WcXFTwieHemstbdnIrXulgtwOZiW17RzVm2vz2wdfN7hf010cB+qf5DDL3efI yLucAFB/XMEQZ7lO4/fC1BV9LTmNRt3vU4mCnOxLOhhxu1fLqYdG6bgC8H32wup+Bu1H MYgrX7bq5PyAfNmvU9pLbxDY5itzwfZYwlmRFTE8/pgxEAL5FP3cvLpsD1nxHMh/hqPS RTex+9DfYThVCnJr6DLpcN32YCjFcb1rh3J+p/4OmSKJXMBv2VOAYm6hF8VUo04D4+xV PMFJGd8slIS5yZaaigsYT9kB2vXcHPD05Fk+/qyl3iQwAY9BOwvvrHXW9AvEgn1mettO 29OQ==
X-Gm-Message-State: AGi0Pub88Jexb9shQqO4GKR6W89cLViW+FIrn0ubZiTVyjBDTtSZrHIK BdGtUpgxxJNX7U/od6t640tmbCp2cnpb7Yujcp/dzA==
X-Google-Smtp-Source: APiQypJEo3XlWyXyDMjlc5QBih7ewWwyiQGNFb+Vm3SKzaNLIZTKzZTYFqweRMz+KGnp4hesZrrANU+Tskj05Yd0tnA=
X-Received: by 2002:a5d:694a:: with SMTP id r10mr21375359wrw.228.1586830460046; Mon, 13 Apr 2020 19:14:20 -0700 (PDT)
MIME-Version: 1.0
References: <9A77145D-1506-4DC4-ADE2-9C5BD4B2AC86@cloudflare.com>
In-Reply-To: <9A77145D-1506-4DC4-ADE2-9C5BD4B2AC86@cloudflare.com>
From: Chelsea Komlo <chelsea.komlo@gmail.com>
Date: Mon, 13 Apr 2020 20:14:07 -0600
Message-ID: <CAJoqpTLLeqpaA6YN5V99vX-P6B1G_NGGC2T8cyP5zt5k6pUnVw@mail.gmail.com>
To: privacy-pass@ietf.org
Cc: Matthew Finkel <matthew.finkel@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e3d1ea05a336c1f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/7IXHIdXy7bEg3OMlScihmNKFRx4>
Subject: Re: [Privacy-pass] Questions on client trust
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 02:14:24 -0000

Hi all,

We are submitting this feedback as core contributors of the Tor Project
(although not speaking on behalf of Tor), to assess the draft for user
privacy and anonymity. We are happy to continue providing reviews going
forward from this angle.

We will start with a few meta-comments, and then discuss Alex's points
in-line.

First, the draft targets "privacy-preserving authorization", however, if
clients do not use a network anonymity tool such as Tor, clients can be
trivially tracked (ignoring all proposals that place complete trust in
single entities such as IP blindness or VPNs). Hence, we assume that users
of anonymity networks such as Tor are a core motivating use case of Privacy
Pass (as they were for the original paper). We suggest adding Tor users to
a "Motivating Use Cases" section to the draft (and other noteworthy cases)
to ensure this use case is not lost throughout the standardization process.

Second, we note the change of wording in the draft from "anonymously
authorizing" to "privacy-preserving authorization". We recommend using the
phrasing "anonymously authorizing" due to its stronger guarantees to end
users.

Third, we wish to highlight the lack of detail on trusted registries and
the potential harm to users that could occur if registries cannot not be
trusted. If registries are secretly malicious, users can be trivially
tracked (by the registry colluding with malicious issuers to distribute
unique public keys). As such, we suggest adding stronger mechanisms to the
draft to ensure registry trust.

Fourth, we suggest adding a strict upper bound to the number of bits of
information that can be encoded into tokens, if this capability is added to
the draft or an extension. Clearly, the larger the number of possible
anonymity sets, the more fingerprintable users become. Consequently, we
suggest upper bounding this number, and to keep it small.

On Thu, Apr 2, 2020 at 4:44 AM Alex Davidson <adavidson=
40cloudflare.com@dmarc.ietf.org> wrote:

> Hi all,
>
> Following on from the previous email. There were some initial questions
> raised during the BoF that will be important to discuss before we
> proceed to rework the charter. The most immediate questions are the
> following:
>
> - To what extent should client's trust the issuers when redeeming
> tokens?
>         - Under what conditions should they accept/redeem tokens?
>         - What information does the client trust the issuer to encode in
> the
>         tokens?
> - How does an ecosystem protect itself against issuer consolidation
> and/or centralization?
>
> The first point is not currently covered by the current charter or docs.
> For example, a helpful measure would be for the client to check the size
> of the anonymity set that it is part of. Such considerations are
> required to be made for any client looking to use an
> anonymity-preserving tool. However, checking such measures appears
> difficult in the ecosystem that we are looking to construct. There are
> currently only recommendations in the architecture doc for redeeming
> tokens to reduce the impact of an issuer being able to target a specific
> client. I think providing practical mechanisms for allowing clients to
> make decisions on which issuers to trust is something that we will be
> able to do (such as specifying client/consumer allow-lists). But,
> providing the actual measures that the client uses to make these
> decisions appears (at least to me) to be beyond the scope of what can be
> achieved with the current design.
>

While indeed the task of ensuring client trust requires adding additional
details to this draft, it is critical to ensure its effectiveness for its
intended use case.

For users to be sure they are part of a sufficiently large anonymity set,
they should be sure that 1) their tokens do not have a large number of bits
encoded into them, 2) their registry is trustworthy, and 3) the issuer that
a user holds tokens from has issued a sufficiently large number of tokens
to other users. The first two points can be reasonably verified from a user
side; thus, we suggest including such mechanisms in the draft. The last
point (regarding number of tokens an issuer has distributed) seems harder,
but should be given more thought.

Thanks,
Chelsea Komlo and Matt Finkel