[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03                                                   
Privacy Pass                                                M. McFadden
Internet Draft                            internet policy advisors, llc
Intended status: Informational                         November 2, 2020
Expires: May 2, 2021

              Privacy Pass: Centralization Problem Statement

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 2, 2021.

Copyright Notice

   Copyright (c) 2020 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
   (http://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.

McFadden                  Expires May 2 2021                   [Page 1]

Internet-Draft     Centralization Problem Statement       November 2020


   This document discusses the problems and mitigations associated with
   strict upper bounds on the number of Privacy Pass servers in the
   proposed Privacy Pass ecosystem. It documents a proposed problem

Table of Contents

   1. Introduction...................................................2
   2. Potential Privacy Concerns.....................................3
   3. Centralization in Privacy Pass - Problem Statement.............4
      3.1. Architectural Problems....................................4
      3.2. Engineering Problems......................................5
      3.3. Practical Problems........................................6
   4. Problem Statement and Potential for Mitigations................6
      4.1. Problem Statement.........................................6
      4.2. Potential Mitigations.....................................6
   5. Security Considerations........................................7
   6. IANA Considerations............................................7
   7. References.....................................................7
      7.1. Informative References....................................7
   8. Acknowledgments................................................7

1. Introduction

   The Privacy Pass protocol provides a set of cross-domain
   authorization tokens that protect the client's anonymity in message
   exchanges with a server.  This allows clients to communicate an
   attestation of a previously authenticated server action, without
   having to reauthenticate with user intervention.  The tokens retain
   anonymity when this is defined as the act of revealing them cannot
   be linked back to the session where they were initially issued.

   The protocol itself in defined in [1] and the architectural
   framework is in [2].

   The architecture document leaves for a later time the issue of
   server centralization.  This document is a discussion of the
   problems related to server centralization in Privacy Pass, the
   impact of centralization on the protocol's privacy goals, and some
   potential mitigations for the problem.

   An important feature of the Privacy Pass Architecture is the concept
   of the anonymity set of each individual client. The Privacy Pass

McFadden                  Expires May 2 2021                   [Page 2]

Internet-Draft     Centralization Problem Statement       November 2020

   ecosystem has a set of servers which issue tokens to clients which
   can then be redeemed at the application layer for authentication.

   Trust is an important component in Privacy Pass. The servers have to
   publish their public keys and details of the ciphersuite they are
   using. It is necessary to publish these in a globally consistent,
   tamper-proof data structure. Clients that use the same registry of
   server information need to coordinate in some way to validate that
   they have the same view of the registry and its data.

   Four server running modes are discussed in [2]. Common to all four
   is a discussion of the need to set an upper limit on the number of
   servers that are allowed. The motivation for limiting the number of
   servers is that there is a correlation between larger numbers of
   servers and dilution of privacy.

2. Potential Privacy Concerns

   When a client redeems a token in Privacy Pass, there is very little
   information in the token itself other than the key that was used to
   sign the token. A key feature of the protocol is that any client can
   only remain private relative to the entire space of users using the

   In three of the four server running modes, a Privacy Pass verifier
   is able to trigger redemption for any of the available servers. The
   greater the number of servers, the greater the loss in anonymity.

   The architecture document [2] provides an example where, if there
   are 32 servers, then the verifier learns 32 bits of information
   about the client. In certain circumstances, having that much
   information about the client can lead to the client being uniquely
   identified and the goals of Privacy Pass thwarted. As a result, the
   architecture document supplies the following mitigation:

   "In cases where clients can hold tokens for all servers at any given
   time, a strict bound SHOULD be applied to the active number of
   servers in the ecosystem." [2]

   Putting restrictions on the number of redemption tokens at the
   client is considered. It is not clear whether reducing the number of
   redemption tokens would continue to meet Privacy Pass' stated
   privacy goals.  However, establishing control of the client, and the
   number of tokens it has, is far more difficult than restricting the
   number of active servers.

McFadden                  Expires May 2 2021                   [Page 3]

Internet-Draft     Centralization Problem Statement       November 2020

3. Centralization in Privacy Pass - Problem Statement

   For Privacy Pass to succeed clients must be able to acquire tokens
   that they can later redeem with greater privacy and anonymity than
   in typical manual or user-mediated authentication. This document
   does not discuss the goals of privacy or anonymity. Instead, it
   identifies a problem related to the upper bound in number of servers
   that affects the Privacy Pass ecosystem.

   For the purposes of this draft, "server centralization" is the
   strict limit or upper bound in the number of servers available from
   which a client can acquire a token for later redemption.

   The architecture draft specifies an upper limit of four for this
   upper bound.

   The problem statement for Privacy pass can be summarized: an upper
   bound to available Privacy Pass servers creates architectural,
   engineering and practical problems for the deployment of the
   protocol. Any successful deployment of Privacy Pass must find
   mitigations for these problems.

3.1. Architectural Problems

   Centralization is a problem space that has been exhaustively
   explored by others; not least of which in the IETF itself. The now
   expired IAB draft [3]] discussed six separate issues related to
   centralization and several of them appear to apply to Privacy Pass.
   Those issues were:

   o single points of failuyre

   o surveillance

   o concentration of information

   o effect scope

   o interaction with other issues

   o the effect on differing expectations and jurisdictions

   Having a very limited number of servers available creates an
   architectural strain on avoiding single points of failure.  While
   the Privacy Pass architecture document does specify up to four
   servers, this is a very small number for, potentially, billions of
   possible users. The context of Privacy Pass appears to assume that

McFadden                  Expires May 2 2021                   [Page 4]

Internet-Draft     Centralization Problem Statement       November 2020

   the protocol is only used in "human-to-server" applications.
   However, it is possible to imagine it being used in situations where
   the client is not a human, but some other device - either acting on
   behalf of a human or autonomously. Strict limitations on the number
   of servers poses the question of how the Privacy Pass architecture
   can scale in the presence of a large client base.

   The Privacy Pass architecture, by limiting the number of servers,
   also concentrates information and potentially limits the ability for
   other competing providers of the token generating services. By
   concentrating the information in a small number of servers, a
   problem appears when there are machine learning opportunities to
   collect and process data about clients requesting tokens. The
   problem also appears when the issuing server also has access to
   other metadata or requests from the client (for instance, DNS
   resolution requests or cached objects returned as part of HTTP

   A side effect of limiting the number of servers is that a
   significant amount of information ends up being in the control of a
   small number of entities. A client may trust a Privacy Pass server
   as send it information about itself in order to request tokens.
   However, the protocol itself can make no guarantee about the data
   handling practices of the server operator. A potential protocol
   design goal should be to minimize the opportunities for abuse by the
   server operator.  Situations outside the control of the protocol may
   make it so there are pressures to misuse the data concentrated at
   the small number of servers.

3.2. Engineering Problems

   In the event that a very limited number of servers can be provided
   while still supporting the goals of the protocol, there is clearly a
   global scaling problem that needs to be solved. Each server must
   publish a global, consistent and protected view of its published key
   and the cryptosystem in use. Without access to that view, the system
   appears to have no failure mode.

   With a small number of servers, the ecosystem would likely be
   dominated by a few providers. With a dominant position in the market
   these Privacy Pass server operators would have a significant impact
   on default connectivity parameters in operating systems and
   browsers. As a result, a change to the way the access mechanism
   works for a variety of applications would have broad impacts to a
   wide variety of users. The relationship between engineering and how
   it affects a broad community of users has a recent example in DNS
   over HTTPS [4].

McFadden                  Expires May 2 2021                   [Page 5]

Internet-Draft     Centralization Problem Statement       November 2020

3.3. Practical Problems

   Limits to the number of server operators also results in practical
   problems outside the protocol. In the event that a small number of
   server operators appear in the Privacy Pass ecosystem, and a large
   number of clients enter into trust relationships with those
   operators, what happens when those operators are acquired by other
   organizations that have different data handling and privacy policies
   than the original operator?

   With the requirement for a small number of operators, the
   architecture also doesn't consider the possibility that an
   organization or government could require Privacy Pass and the use of
   a particular set of servers. Such a requirement could potentially
   turn the goals of Privacy Pass against itself.

4. Problem Statement and Potential for Mitigations

4.1. Problem Statement

   An upper bound to available Privacy Pass servers creates
   architectural, engineering and practical problems for the deployment
   of the protocol. Any successful deployment of Privacy Pass must find
   mitigations for these problems.

4.2. Potential Mitigations

   The motivation for having an upper bound to available Privacy Pass
   servers is to limit the amount of information that could be gathered
   because a client could be forced to redeem tokens for any issuing
   key. A large number of keys means a greater about of information

   One alternative to limiting the number of servers is to constrain
   the clients so that they only possess redemption tokens for a small
   number of servers. This potential mitigation doesn't address how the
   tokens might be cached, but it does discuss how the limitation might
   be implemented. However, there is much engineering experience to
   suggest that making a limitation work in a very large number of
   clients is a much greater engineering and deployment problem than
   placing the restriction in the server.

   If the motivation for restricting the number of servers is essential
   for Privacy Pass - and the mitigations at either the server or
   client are difficult to overcome - it is hard to understand where
   the mitigations for the problem statement will emerge.

McFadden                  Expires May 2 2021                   [Page 6]

Internet-Draft     Centralization Problem Statement       November 2020

5. Security Considerations

   This document is all about security considerations for Privacy Pass.
   In particular, it addresses the very specific problem associated
   with centralization of Privacy Pass servers.

6. IANA Considerations

   This memo contains no instructions or requests for IANA. The authors
   continue to appreciate the efforts of IANA staff in support of the

7. References

7.1. Informative References

   [1]      Davidson, A. (Editor) "Privacy Pass: The Protocol",
   Internet-Draft, https://datatracker.ietf.org/doc/draft-davidson-pp-
   protocol/ July 2020

   [2]      Davidson, A. (Editor) "Privacy Pass: Architectural
   Framework", Internet-Draft, https://datatracker.ietf.org/doc/draft-
   davidson-pp-protocol/ July 2020

   [3]      Arkko, J., Trammell, B., Nottingham, M, Huitema, C.,
   Thomson, M.,  Faber, T., Tantsura, J., ten Oever, N., (editors),
   Internet-Draft (expired), https://datatracker.ietf.org/doc/draft-
   arkko-iab-internet-consolidation/ July 2019

   [4]      Hoffman, P., McManus, P. (editors), RFC 8484, "DNS Queries
   over HTTPS (DoH), January 2019

8. Acknowledgments

   The goal of this draft is to meet the requirement in the charter of
   Privacy Pass that states: "Risk assessment for centralization in
   Privacy Pass deployments for multiple design options - February 2021."
   In particular, the author would like to thank the many speakers at the
   March and July 2020 Privacy Pass working group meetings who expressed
   reservations about the centralization features of the protocol design.

   This document was prepared using 2-Word-v2.0.template.dot.

McFadden                  Expires May 2 2021                   [Page 7]

Internet-Draft     Centralization Problem Statement       November 2020

Authors' Addresses

   Mark McFadden
   Internet policy advisors, ltd
   Chepstow, Wales, United Kingdom

   Email: mark@internetpolicyadvisors.com

McFadden                  Expires May 2 2021                   [Page 8]