Re: [Privacy-pass] Questions on client trust

Chelsea Komlo <chelsea.komlo@gmail.com> Thu, 07 May 2020 03:09 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 475953A0496 for <privacy-pass@ietfa.amsl.com>; Wed, 6 May 2020 20:09:04 -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 dbF0HFL0ehji for <privacy-pass@ietfa.amsl.com>; Wed, 6 May 2020 20:09:02 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 3ED7C3A048D for <privacy-pass@ietf.org>; Wed, 6 May 2020 20:09:02 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id u16so4953109wmc.5 for <privacy-pass@ietf.org>; Wed, 06 May 2020 20:09:02 -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=L63VEOgcE8HB0Dujmrln6FgDvs0nydUlF25IsbruZ+g=; b=ROdXYnJ5ITcCqw42R6fbFszBgi6cDsfELSau81qWyhiTop9DMwkFwmF20j3zNKY/fr NEYrRb6CXx7aF5zamTsG89u5mXa1+ok0nq+jJ8pPmBnqQbVdGUEWzFSb10w4lQeo5IRI o+BLSGXEPvOEh7FfAFzRB1ZHD0GgPN2xMd2r881fzFfnr7U9aIIuTdRie9NrOd+tC2xv UBKI2P00DpmGByS7exPdYpdf5jy5Gao+4OfnbyfOoUFy0tnajrDy6ZzJKKsTdXmnOu3c aBJSEIX+a2LmKUs+0UAacp6P/ucByAoxgLBgNd8xrVBA4HfwXnQ7aaSOV3bcBMN3Kfic YtcA==
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=L63VEOgcE8HB0Dujmrln6FgDvs0nydUlF25IsbruZ+g=; b=uEL3F0fsmLcQ3q/PWh8A/ySAM5pl8QkGyvtThD0mizoXzafNScEDLP6xS0im0cslyH 3QtQRlEAG+9R2PgJIK0vu7iVmh/X/xh+TwnNHLwFRj4of9OULrbrOQ9kAK4gHSOnfmod X/I9wzIT9mtW/etr5z0pyx3sFrSdNTF2jiGlr3zrexjODSHJYK4DhyLpxzwsBYEe6hL5 DOwVugGVKTo7ZLamG8/HxxZ0U5WIvvLzllaUnu+INClgSoAU+QXbwgRS7tClbsoY9FlG c63rTFkH42glDmLrkLNA0WGx8tIpeewSMiBGSWl1UFWs7+0IX/XoyXkI60nrNm09KSu1 sOYQ==
X-Gm-Message-State: AGi0PubcaZlwy+7GfvBCQuoXsoc6k4X5cPHPfxDxuQFl4CNOC4nlxZax JEZScCOyGfvBTNGVNfLtPYv+CF0hjXO/80gvZPc=
X-Google-Smtp-Source: APiQypJpaNFiyM+4aQRbYGUiUlr2CA9j3CGSqqSNCmdiN2IqZ7rtGPGU7bDwxpKmo4MWiQBXkxHVe82FMbsdNyR+Tyo=
X-Received: by 2002:a1c:4d07:: with SMTP id o7mr8332948wmh.59.1588820940552; Wed, 06 May 2020 20:09:00 -0700 (PDT)
MIME-Version: 1.0
References: <9A77145D-1506-4DC4-ADE2-9C5BD4B2AC86@cloudflare.com> <CAJoqpTLLeqpaA6YN5V99vX-P6B1G_NGGC2T8cyP5zt5k6pUnVw@mail.gmail.com> <E665BB52-805F-4640-A975-7989379F1BFD@cloudflare.com>
In-Reply-To: <E665BB52-805F-4640-A975-7989379F1BFD@cloudflare.com>
From: Chelsea Komlo <chelsea.komlo@gmail.com>
Date: Wed, 06 May 2020 21:08:48 -0600
Message-ID: <CAJoqpTL12D3nu41XMdqjPaA3gcspO+=LkDJyQDXSbQmPJShcYQ@mail.gmail.com>
To: Alex Davidson <adavidson@cloudflare.com>, privacy-pass@ietf.org
Cc: Matthew Finkel <matthew.finkel@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c5feaa05a5063319"
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/ZUpyWKhN2EtET9lG_PZneGWo03M>
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, 07 May 2020 03:09:05 -0000

Hi Alex,

Thanks for opening these issues- looking forward to these discussions.

On Tue, Apr 14, 2020 at 5:24 AM Alex Davidson <adavidson@cloudflare.com>
wrote:

> Hi Chelsea & Matt,
>
> Thanks for taking the time to review the current documents. Your insights
> are really valuable and raise a number of points that do indeed require
> addressing. I’ve inlined my responses below.
>
 [...]

> I agree that trusted registries are still not very well-defined. I expect
> that, if we decide to go down the trusted registry route, the user-registry
> trust dynamic will be similar to the trust dynamic between user and Issuer.
> We will need mechanisms for the clients to ascertain the state of this
> dynamic and subsequently act on that. Ideally, we would have some more
> discussion on whether the trusted registry approach is the right path to
> take, or whether an alternative approach may be better suited (such as
> those raised by Steven in the BoF).
>
>
After thinking through how to verify registry behavior more, one additional
consideration that may be worth exploring is immediate versus eventual
verification/detection. While immediately detecting a registry's
misbehavior is ideal, if this approach proves too difficult to implement in
practice, it could be worth exploring if a relaxation to eventual detection
is a more acceptable alternative.

One simple example I can think of for eventual detection of registry
misbehavior is in the setting of Tor (but could be adapted more broadly).
Clients could easily build several different circuits to a registry to
request an issuer's public key, so the attack of selectively issuing
different public keys is more difficult to hide (as the registry cannot
differentiate a single client with multiple different Tor circuits from
multiple different clients). I suspect there are other smaller-scoped
alternatives in this category.

Thanks again,
Chelsea