Re: [Privacy-pass] Questions on client trust

Alex Davidson <adavidson@cloudflare.com> Tue, 14 April 2020 11:50 UTC

Return-Path: <adavidson@cloudflare.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 35FB13A0CF5 for <privacy-pass@ietfa.amsl.com>; Tue, 14 Apr 2020 04:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key) header.d=cloudflare.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 FSBET4QP-bFa for <privacy-pass@ietfa.amsl.com>; Tue, 14 Apr 2020 04:50:44 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 8559A3A0CF4 for <privacy-pass@ietf.org>; Tue, 14 Apr 2020 04:50:44 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id z6so13632153wml.2 for <privacy-pass@ietf.org>; Tue, 14 Apr 2020 04:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzllZjoxBNtRPBmOvfkBfQnh9DfXYD0vVN7ZxJrwEA0=; b=dT+0uIVq+lG/NVMN2Q2iMOIph4f8QJ91eLbuSF0XsKxEYM8mzkDKfbGL3v71okuTKg 3AQuPwi9r2R5Gf/QpFPsXKJ/3IBZ/+helUBH/45VoDZbmSDLk5CRky/zZL/GuMG+MN++ fvuZbjqL9tMQsMoTaNDGKLz9fGMk9pNNGlBMc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzllZjoxBNtRPBmOvfkBfQnh9DfXYD0vVN7ZxJrwEA0=; b=UAZ8n8BY4EzeTbcsyL73RW+4FX4cB//kPOSBLlQtJh0UXMHoyAYrqRXkGdoKp33gOX /TwDkgS9totX7H7AhlTknrb3mpu47T5cMUx89meqRDx6DweQZ5oPLVVq+OmU091WV7Ng xEmALZ3pNvGnTAKQ418WSVWJFbFwvZ+V2QsXziQISIPNMKbNxK9lJH54TeJtVQlB12sR uX1pmINReny37ge2cSoioH5O6878dh8aoLB2ApN2rwEm8+ndHMoLLPJq2Cab7sIxV1mU kM7vUL1xs6UkAORSGRfQTAZy5sxtvUpV2HCHTjz7ss0jLcpe4YMLVswgKo5WIgUQLQ+x EnYg==
X-Gm-Message-State: AGi0PuYjmhdOiSikTi7xpxF8ZM2+ne6nrHRgtiltQ2UJBA0zrazsJXjd BD7120D22AlHo1Qht1CPyRxE9EbLQPQ=
X-Google-Smtp-Source: APiQypLyuk7Z7ByJtunCEChuOiD5YH0zXHSX75L6jHLhiGz72+RYYMQG97ocLP6TYbCEpSAXCzjoPg==
X-Received: by 2002:a05:600c:2945:: with SMTP id n5mr6792315wmd.148.1586865042614; Tue, 14 Apr 2020 04:50:42 -0700 (PDT)
Received: from ?IPv6:2001:8a0:7ac8:f600:7d4f:bcd:61e1:903a? ([2001:8a0:7ac8:f600:7d4f:bcd:61e1:903a]) by smtp.gmail.com with ESMTPSA id c190sm18396863wme.4.2020.04.14.04.50.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2020 04:50:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alex Davidson <adavidson@cloudflare.com>
In-Reply-To: <439fd8f8-5942-4f4a-94fd-672d3de76f13@www.fastmail.com>
Date: Tue, 14 Apr 2020 12:50:38 +0100
Cc: privacy-pass@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F31C1153-9C53-41AC-B461-145DA5F038D0@cloudflare.com>
References: <9A77145D-1506-4DC4-ADE2-9C5BD4B2AC86@cloudflare.com> <CAHbrMsBfsJ1+ueTZBnsQxXiHQHkGLHG=j+5R8FgeJwt5nooQzw@mail.gmail.com> <439fd8f8-5942-4f4a-94fd-672d3de76f13@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/du5zBhPge3XXy0wt4qoKKeV4osw>
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 11:50:46 -0000

> On 14 Apr 2020, at 03:43, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Tue, Apr 7, 2020, at 04:57, Ben Schwartz wrote:
>> On Thu, Apr 2, 2020 at 6:44 AM Alex Davidson 
>> <adavidson=40cloudflare.com@dmarc.ietf.org> wrote:
>>> - 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?
>> 
>> Since we are chartering, not designing, I think it's premature to try 
>> to solve these problems. At this stage, our goal should be to describe 
>> (1) the problems and (2) the scope of our ambition to address them.
> 
> I think that this cuts to the core of the question of feasibility.  That is, is this a research project or an engineering task?
> 
> There are two paths that avoid having to deal with these questions:
> 
> 1. pick a single manifestation of the system, like "is human", build to that, and document this
> 
> 2. make it very clear that the way in which the token conduit acts is very much subject to some amount of trust in the token issuer, explain that any carriage of token across what might otherwise be a privacy boundary requires that this trust exist, and build the system with that in mind
> 
> The original charter might have been a shade more biased toward the latter approach, but the designs I saw included mechanisms that seemed to derive from a viewpoint that had less inherent reliance on trust.  The designs implied (at least to me) an assumption that the conduit didn't need to think or trust.  That might be possible for the "is human" bit in browsers, maybe, so that's not unreasonable.  That made this hard to assess because of those implicit assumptions.

I would rather not scope as narrowly as “is human” as I think some of the proposed applications being considered are somewhat broader than that specific signal. I think the path that is raised in 2) is close to the direction that I was personally imagining that we would take. My preference would be to assume that the client has decided which Issuers/Registries/Vendors that it can trust and then build the protocol and architecture with this trust already established. There may be ways that we can provide broad recommendations on how clients may want to make this decision (e.g. based on the past behaviour of the Issuer in interactions, key rotations etc.) but going beyond that seems beyond the scope of the work, in my opinion.

>> As often seems to be the case, I think we are not really talking about 
>> "more" or "less" consolidation, but rather trading off consolidation 
>> pressure in different elements of the ecosystem. The charter should 
>> acknowledge that some degree of consolidation pressure may be 
>> unavoidable, but we will do our best to minimize and mitigate it. 
> 
> This notion of how protocols act to shape market pressures is new for us here, so it might be OK to call it out as special.  We used to do that for security until it was sufficiently internalized.  However, we need to remember that this is just another factor we should each consider as we go through this process.  I don't want to over-rotate on consolidation when we also need to consider environmental impacts, the effect on underrepresented minority groups, accessibility, privacy, or any of a number of other important factors.
> 
> The apparent need for trust of certain types in this system does tend to produce certain consolidation pressures that we need to acknowledge, but until we understand the precise role of trust, we can't know for sure.  What is worse, the details of the information being conveyed likely has more of an effect on this than anything else, and it seems like there is a desire to make the information conveyed flexible.
> 
> Maybe the consolidation thing is manageable for something like an "is human" assertion, but is completely intractable in the general case.  And maybe that is OK from a consolidation perspective because the protocol is completely unusable at global scale for any other sort of assertion.  And maybe that is terrible because it means the creation of islands of haves and have-nots for privacy pass.  (And maybe I should stop extrapolating from zero information.)
> 

I think these are all valid things to consider regarding the issue of consolidation and its relationship with the trust dynamic between a client and the rest of the ecosystem. I agree with Ben that aiming to minimise this pressure in the design of the protocol architecture is something that we can commit to in the charter. We can then better establish in future documentation exactly how this mitigation would work, and how concerns of the nature that Martin has surfaced interplay with each other. I also agree that making a concrete assertion about the type of signals that the protocol can provide (“is human” or otherwise) is going to be essential in being able to answer these questions.

Alex