Re: [Privacy-pass] Questions on client trust

Chelsea Komlo <chelsea.komlo@gmail.com> Thu, 16 April 2020 02:48 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 93DAF3A09C7 for <privacy-pass@ietfa.amsl.com>; Wed, 15 Apr 2020 19:48:23 -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 gGDwVPvN2atL for <privacy-pass@ietfa.amsl.com>; Wed, 15 Apr 2020 19:48:21 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 ECA0B3A09C6 for <privacy-pass@ietf.org>; Wed, 15 Apr 2020 19:48:20 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id c195so1411991wme.1 for <privacy-pass@ietf.org>; Wed, 15 Apr 2020 19:48:20 -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=oOR46eBJJ0IJr9WpyxkEy0ua968U5igze6wQt4MKXnE=; b=OC2wsazFCg/7oJhyL7bLGKBq5EDUbcVsT/le1tR68VbNs5mycWSSnEi1+1CIz8Imnj F3DXmUyYMnRxwV7hL+RdHNJhkXn6P6fxzkKdAcy9rW6soxhja6ERowQtJnhoEoOmV8vs uINPdQlgqkF9M2xI27vZKboSz2qGQuJ2Hrv4PaRcMnrUzklhkw7ZuAsxPgWAJPmit5ls xiMl9uG0Q7VxHoauSIn3v+sqgshf8PL9U2Q0sLyYtYr1Tvo3VMs0id2ZhW0VEBPBmYOG ODmdknqvapBwiCVi67UtUX99wwiHRexCwe1l2I2Fa9kL3jP7LxPMDsrKeauyWRMjFJdm AdeA==
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=oOR46eBJJ0IJr9WpyxkEy0ua968U5igze6wQt4MKXnE=; b=O8T2zkuh61d2pPckIoJ0NhG/NdjIGIHE9xIcMDX9TMElc7BblTwezNu3oP6pFqtgB6 K4ntu/T3/ZPoWusL2SZ2r0TBXvULCIz1eJDlufC4gd59evgJhCQDmXKKD1ubN0aHT8pa K7obue0Qf1Gzd7EW9PiwfO7v58nkchfHeTpyRmVfRPxtU5LqkFXoYG6M/sjcpyOMt6qh j61te7iDDv8qBVldONU4JmJmybXF5EygGARWtN0lhFKzzsgzL/QMq1Uze/KyqsoUsVvA NVVQuhzwcbEE8DeYwYXsZCwi1Jo0heWGIb5l5mKx+O9WonEBhlnddjpMOEssSZyP4jGU HB6w==
X-Gm-Message-State: AGi0PubBQEwapi3HvStwlV15CQMZ98LN11cnxZGS/Oc8Gs6hZVxmQNxG XFtcA2e/L1PFN7qPOrLehwBrDmUnCLUeTK340f4=
X-Google-Smtp-Source: APiQypLmxqWDyVms6+Z36GC1xGO6r+6OI+u891/TlSKf+F4CX/FPdPVPt7Z1s6vjfg6t69BuSvO26BuIbzmzTBTMZP4=
X-Received: by 2002:a1c:9aca:: with SMTP id c193mr2264195wme.38.1587005298558; Wed, 15 Apr 2020 19:48:18 -0700 (PDT)
MIME-Version: 1.0
References: <9A77145D-1506-4DC4-ADE2-9C5BD4B2AC86@cloudflare.com> <CAHbrMsBfsJ1+ueTZBnsQxXiHQHkGLHG=j+5R8FgeJwt5nooQzw@mail.gmail.com> <439fd8f8-5942-4f4a-94fd-672d3de76f13@www.fastmail.com> <F31C1153-9C53-41AC-B461-145DA5F038D0@cloudflare.com> <CAHbrMsDZTMF+2SwB3yp16muP3sQT-v=ieFCFafu_5u65T8tkuQ@mail.gmail.com> <CABcZeBP4KdD9hWrr6+4u9v+3zTbQmhsa5fGdRfeSZXpzHumV2w@mail.gmail.com> <CAHbrMsC2v1ydF4V+4Nyz_fUsAML_D_8fh8MMcrEJm+McXS1QDA@mail.gmail.com>
In-Reply-To: <CAHbrMsC2v1ydF4V+4Nyz_fUsAML_D_8fh8MMcrEJm+McXS1QDA@mail.gmail.com>
From: Chelsea Komlo <chelsea.komlo@gmail.com>
Date: Wed, 15 Apr 2020 20:48:06 -0600
Message-ID: <CAJoqpTJ9X=F9_hKUQf+sXAg3F50_FAm5y+PZK7NEG2r9u_jHMw@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>, Alex Davidson <adavidson@cloudflare.com>, Martin Thomson <mt@lowentropy.net>, privacy-pass@ietf.org
Content-Type: multipart/alternative; boundary="00000000000013cb3b05a35f774f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/Y-G_UaLkTs6xAok4eCL7mbXYXG4>
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: Thu, 16 Apr 2020 02:48:24 -0000

On Wed, Apr 15, 2020 at 12:16 PM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

>
> On Wed, Apr 15, 2020 at 12:09 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> On Tue, Apr 14, 2020 at 8:53 PM Ben Schwartz <bemasc=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>
>>> I think we should rule all content (blind signing) strictly out of
>>> scope.  The complexity of supporting content is not worth it for N<4 bits;
>>> just encode the content in unary by the choice of issuer.  If that proves
>>> too inefficient after this is all finished, we can consider a follow-on
>>> specification with content.
>>>
>>
>> A number of the obvious applications of this kind of technology require
>> content and probably > 4 bits. I don't think we should go to the trouble of
>> designing a protocol as inflexible as you suggest.
>>
>
> In that case, we should mention an example of such an application in the
> charter.  However, I would want to think carefully about whether the use
> case retains enough anonymity that all this cryptography matters.
>
>

With every bit that is added, the growth in the number of anonymity sets
that a user can fall into grows exponentially. The protocol will need some
degree of inflexibility to ensure that users have strong guarantees against
tracking by issuers- a core purpose of Privacy Pass.

Putting hard bounds on the number of bits seems to be the most controllable
lever for ensuring a large anonymity set, as opposed to regulating the
number of issuers. Consequently, the number of bits should be kept low to
ensure the protocol's effectiveness to protect user privacy.

Chelsea