WG Action: Formed Privacy Pass (privacypass)
The IESG <email@example.com> Fri, 10 July 2020 16:34 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5B33A0FAE; Fri, 10 Jul 2020 09:34:39 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: The IESG <firstname.lastname@example.org>
To: "IETF-Announce" <email@example.com>
Subject: WG Action: Formed Privacy Pass (privacypass)
Cc: firstname.lastname@example.org, The IESG <email@example.com>, firstname.lastname@example.org
Content-Type: text/plain; charset="utf-8"
Date: Fri, 10 Jul 2020 09:34:39 -0700
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2020 16:34:40 -0000
A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Privacy Pass (privacypass) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Benjamin Schwartz <email@example.com> Joseph Salowey <firstname.lastname@example.org> Assigned Area Director: Benjamin Kaduk <email@example.com> Security Area Directors: Benjamin Kaduk <firstname.lastname@example.org> Roman Danyliw <email@example.com> Mailing list: Address: firstname.lastname@example.org To subscribe: https://www.ietf.org/mailman/listinfo/privacy-pass Archive: https://mailarchive.ietf.org/arch/browse/privacy-pass/ Group page: https://datatracker.ietf.org/group/privacypass/ Charter: https://datatracker.ietf.org/doc/charter-ietf-privacypass/ The Privacy Pass protocol provides a performant, application-layer mechanism for token creation and anonymous redemption. Servers (Issuers) create and later verify tokens that are redeemed by an ecosystem of clients, such that: - An Issuer cannot link a redeemed token to one of N previously created tokens using the same key with probability non-negligibly larger than 1/N. - Clients can verify that a token created by an Issuer corresponds to a committed keypair. - Tokens are unforgeable. - The token issuance and redemption mechanisms are efficient. The primary purpose of the Privacy Pass Working Group is to develop and standardize a protocol that meets these requirements, influenced by applications that have arisen from the wider community. The aims of the Working Group can be split into three distinct goals: First, specify an extensible protocol for creating and redeeming anonymous and transferrable tokens. The protocol should permit suitable cryptographic ciphersuites and security parameterization for cryptographic agility. The cryptographic profile used by the protocol participants will be determined by the specific instantiation of the protocol, and it will be fixed for the duration of an Issuer's committed keypair. We will work closely with the CFRG in determining acceptable cryptographic ciphersuites and parameters that satisfy the security and privacy properties of the protocol. The Working Group will specify a preliminary set of extensions, including Issuer-supplied metadata and cryptographic instantiations that additionally support public verifiability of Issued tokens, and may consider any additional extensions that arise in the future. Security and privacy properties of the protocol shall be well-documented. Formal analysis of the protocol will ensure that the security and privacy properties of the protocol are well-understood and well-documented. Second, describe and develop protocol use cases and properties thereof. This includes, though is not limited to: 1. Describing use cases and interfaces that allow the protocol to be used for those use cases. 2. Defining the privacy goals for each Client during protocol execution, along with expectations placed on the Issuers and the ecosystem at large. 3. Describing recommended parameterization(s) of variables associated with the protocol ecosystem that control the size of the anonymity set that the client belongs to. 4. Describing verification mechanisms for trusting Issuers and their corresponding keying material. Such mechanisms should prevent Issuers from presenting any key material that could be used to deanonymize clients. 5. Describing the procedure for including small amounts of metadata with Issued tokens, as well as the associated impacts on privacy. 6. Describing the risk and possible ramifications of Issuer centralization, and exploring possible mechanisms to mitigate these risks. Third, and finally, specify a HTTP-layer API for the protocol. This includes a common understanding of how Privacy Pass is integrated with HTTP requests and responses for web-based applications. The following milestones (along with the approximate dates of completion) will be used to judge the progress of the working group: - Specification of protocol & surrounding architecture - February 2021. - Risk assessment for centralization in Privacy Pass deployments for multiple design options - February 2021 - Specification of application-layer requirements (including HTTP integration) - June 2021. - Specification of HTTP browser API (in coordination with W3C) - October 2021. Note that the specifications developed by this working group will be informed by the following initial drafts: - draft-davidson-pp-protocol-00; - draft-davidson-pp-architecture-00; - draft-svaldez-pp-http-api-00. These existing drafts may be further developed into the core deliverables of the working group, supplemented by any additional extensions. Alternatively, they may contribute indirectly to a future set of documents that meet the core goals of the working group.