Privacy Pass Architectural Framework
draft-ietf-privacypass-architecture-00
Network Working Group A. Davidson
Internet-Draft LIP
Intended status: Informational 5 January 2021
Expires: 9 July 2021
Privacy Pass Architectural Framework
draft-ietf-privacypass-architecture-00
Abstract
This document specifies the architectural framework for constructing
secure and anonymity-preserving instantiations of the Privacy Pass
protocol. It provides recommendations on how the protocol ecosystem
should be constructed to ensure the privacy of clients, and the
security of all participating entities.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 July 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Terminology
3. Ecosystem participants
3.1. Servers
3.2. Clients
3.2.1. Client identifying information
4. Key management framework
4.1. Public key registries
4.2. Key rotation
4.3. Ciphersuites
5. Server running modes
5.1. Single-Verifier
5.2. Delegated-Verifier
5.3. Asynchronous-Verifier
5.4. Public-Verifier
5.5. Bounded number of servers
6. Client-Server trust relationship
7. Privacy considerations
7.1. Server key rotation
7.2. Large numbers of servers
7.2.1. Allowing larger number of servers
7.3. Partitioning of server key material
7.4. Additional token metadata
7.5. Tracking and identity leakage
7.6. Client incentives for anonymity reduction
8. Security considerations
8.1. Double-spend protection
8.2. Token exhaustion
8.3. Avoiding server centralization
9. Protocol parametrization
9.1. Justification
9.2. Example parameterization
9.3. Allowing more servers
10. Extension integration policy
11. Existing applications
11.1. Cloudflare challenge pages
11.2. Trust Token API
11.3. Zero-knowledge Access Passes
11.4. Basic Attention Tokens
11.5. Token Based Services
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Contributors
Author's Address
1. Introduction
The Privacy Pass protocol provides an anonymity-preserving mechanism
for authorization of clients with servers. The protocol is detailed
in [draft-davidson-pp-protocol] and is intended for use in the
application-layer.
The way that the ecosystem around the protocol is set up can have
significant impacts on the stated privacy and security guarantees of
the protocol. For instance, the number of servers issuing Privacy
Pass tokens, along with the number of registered clients, determines
the anonymity set of each individual client. Moreover, this can be
influenced by other factors, such as: the key rotation policy used by
each server; and, the number of supported ciphersuites. There are
also client behavior patterns that can reduce the effective security
of the server.
In this document, we will provide a structural framework for building
the ecosystem around the Privacy Pass protocol. The core of the
document also includes policies for the following considerations.
* How server key material should be managed and accessed.
* Compatible server issuance and redemption running modes and
associated expectations.
* How clients should evaluate server trust relationships.
* Security and privacy properties of the protocol.
* A concrete assessment and parametrization of the privacy budget
associated with different settings of the above policies.
Show full document text