[Privacy-pass] Follow-up: Privacy Pass RWC meeting

Alex Davidson <adavidson@cloudflare.com> Fri, 10 January 2020 17:26 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 201B7120AF1 for <privacy-pass@ietfa.amsl.com>; Fri, 10 Jan 2020 09:26:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 P6n2d3eigT9o for <privacy-pass@ietfa.amsl.com>; Fri, 10 Jan 2020 09:26:20 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 45D9A120AEA for <privacy-pass@ietf.org>; Fri, 10 Jan 2020 09:26:20 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id d71so2580451qkc.0 for <privacy-pass@ietf.org>; Fri, 10 Jan 2020 09:26:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=HsDtVREmnrchsCgfwOsl8KGScdh/q5v7JhtoQDaU83g=; b=tJ64QALOZTh/PogzMpb/HYuAz2AchMPHpu1oe+n5KhJunJD23TJ/ZDEfduEXW/afNQ G6kxdaJ+optLSX0DAPKXR4NM1llSioITQElA5tOZ5Y25TRXs4X4HDNWzq8oaOPt+Ov8k 61m0g0cSVogywsBd0rJYHikTUgzqOzCBkePNc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=HsDtVREmnrchsCgfwOsl8KGScdh/q5v7JhtoQDaU83g=; b=gCJjnOw6ryIcHe/TPgH6HxWO7s4TO+OegGD6cUj5tBpCXhkHEMBtPRXFLKnFld67s0 4GyrMp7ABpZkiq9Bu+58LlJR4kmhVdjqaE+1J9/XxBSDzlBjtpbanCotgjzYOBdqfGlz Zw6cPV13D2eOzcVou5KVGj9ftGQmiekBc/AMOrGgVknP+EmS3nUOrZ9TzmFk4etig1pM 3/qHIMahdp5B7pWxgTiAfDrNFtktydgC6Rgj0UnMBtvBsrsgvfk+aqrwX6e7y4B0scfx XG6N0kudLCl7/KMC5wRxoHbPaR+XXtyjf4WiLX4kn9LJslpcOrHctXDVXMjwdjvOATQh xXBQ==
X-Gm-Message-State: APjAAAXdhQnkyd6HDdlKdFoW+lkLOec878+6dcTRWg/zPvqY5aP9R3Y+ 4/HClJXzOvQ05iXWYuDv/g2PyPi3fGA9oQ==
X-Google-Smtp-Source: APXvYqwLDHT4Ur01fiSchrOf2bKZh1yxXv6iErx+tfRZ4HW3a7aN64Hk3wxzHr/4YcLpqtSFFXrcWw==
X-Received: by 2002:a37:ea09:: with SMTP id t9mr4215865qkj.151.1578677177676; Fri, 10 Jan 2020 09:26:17 -0800 (PST)
Received: from dyn-160-39-226-190.dyn.columbia.edu (dyn-160-39-226-190.dyn.columbia.edu. [160.39.226.190]) by smtp.gmail.com with ESMTPSA id d184sm1139647qkb.128.2020.01.10.09.26.16 for <privacy-pass@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 09:26:17 -0800 (PST)
From: Alex Davidson <adavidson@cloudflare.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB8DC356-1CFE-4B9F-BA78-3F21B07E2B94"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <691C5715-E1F7-4A97-A6A8-D3983733E51E@cloudflare.com>
Date: Fri, 10 Jan 2020 12:26:16 -0500
To: privacy-pass@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/byCuEZJKIlnlF3o21nEOiaEoBso>
Subject: [Privacy-pass] Follow-up: Privacy Pass RWC meeting
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: Fri, 10 Jan 2020 17:26:23 -0000

Hi all,

Thanks to everyone who managed to attend yesterday and contribute to the interesting discussion! We did not quite manage to finish walking through the draft charter and there were also some agenda items that we did not manage to discuss.

With this in mind, perhaps a good way to move forward would be the following:

- I have attached the current iteration of the charter to this email and I have also created a GitHub repository containing it at https://github.com/alxdavids/privacy-pass-wg-charter <https://github.com/alxdavids/privacy-pass-wg-charter>. We can iterate on the charter on list, or using PRs & issues in the GitHub repo.
- We arrange another side-meeting (probably virtual) between now and the time of IETF 107 (21-27 Mar, Vancouver) to discuss the rest of the agenda, which is:
	- Next steps for the BoF process and IETF107
	- Discussion of use-cases
	- Agreement on protocol extensions
- If anyone would like to raise anything separately then we can discuss it on this list.

If we go ahead with the side-meeting, we should aim to have something close to a stable charter. This would allow us to focus on how to move the BoF process forward.

Best,
Alex

Note: I’ve cleaned up the draft a bit based on the notes that were made during the meeting.

==== BEGIN CHARTER ====

The Privacy Pass protocol was first proposed in November 2017 as a performant mechanism for providing privacy-preserving attestation of a previous successful authorization between a human and a server.

The primary purpose of the Privacy Pass working group is to develop and standardize the protocol, influenced by applications that have arisen from the wider community. The main requirements of the working group are to develop a protocol that satisfies the following properties:

Issued tokens are unlinkable with other tokens corresponding to the same anonymity set.
Tokens are unforgeable.
The issuance and verification mechanisms are practically efficient. 

The aims of the working group can be split into three distinct goals that we describe below.

1) Develop the specification of the generic protocol:

Specify the full cryptographic authorization exchange and terminology along with suitable ciphersuites (and security parametrizations) for maintaining security for a meaningful time period.
The negotiation of ciphersuites is determined by the application-specific profile and out-of-scope for this protocol.
Describe the structure of protocol messages.
Describe a framework for extensions to the base protocol for achieving additional functionality, or for providing different security guarantees.

2) Develop the wider architecture for running the protocol
Construct interfaces that make the protocol suitable for integration with potential use-cases.
Including required functions for applications
Document potential applications of the protocol and of its official extensions
Define the privacy goals for each client during the exchange, along with expectations placed on the server and the ecosystem at large.
Analyse mechanisms for tracking via public key and expectations placed on server.
Privacy considerations of incentives for not verifying messages correctly (along with general threat model).

3) Develop document for Privacy Pass in HTTP?
Specify a common understanding of how Privacy Pass data is integrated with HTTP requests and responses for web-based applications.
Specify where key material stored, how it’s accessed, and associated security considerations


Each goal listed above will be fulfilled with an individual document that addresses the necessary conditions. Once these documents are completed, this working group will have concretized a standardized architecture for constructing instances of the protocol. As a consequence, this will enable an ecosystem of applications that depend on the authorization framework provided by Privacy Pass.

In particular, by the time that the working group achieves consensus around these documents, we hope to have a number of interoperable implementations, a clear analysis of the security and privacy considerations, and a diverse ecosystem of concrete applications.

Note that the specifications developed by this working group will be informed by draft-irtf-cfrg-voprf <https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/> which is currently owned by the Crypto Forum Research Group (CFRG@IRTF). In addition, draft-privacy-pass <https://datatracker.ietf.org/doc/draft-privacy-pass/> will serve as a starting point for the work of the working group.

==== END CHARTER ====