********************************************************************** Agenda & Minutes ********************************************************************** IETF 107 Virtual Session - Privacy Pass March 26, 2020 Chairs: Ben Schwartz, Joe Salowey Minutes: Sofía Celi XMPP channel: privacypass@jabber.ietf.org - Introduction & meeting format, speaker: Chairs (5 mins) - Problem statements & use cases, speaker: Alex Davidson - Slides (10 mins) - https://datatracker.ietf.org/meeting/107/materials/slides-107-privacyfpass-privacy-pass-use-cases - Aims of the protocol - Current applications and use-cases - Open discussion (25 mins) * Alex Davidson presented what Privacy Pass is, speacifically, its use cases and problem statement. - The main idea of Privacy Pass is to provide proofs of trust attestation, so that clients don't have to solve challenges every time; instead, tokens are used. - Privacy Pass is a protocol that produces unforgeable tokens that attest to some client attribute. The tokens do not reveal how and when they have been created. - Alex presented the history of the design and development of Privacy Pass. - He also presented how the protocol works, which uses a VOPRF (specification here: https://datatracker.ietf.org/doc/draft-sullivan-cfrg-voprf/) and the different costs of using it. - Cloudflare uses the protocol: CDN issues Privacy Pass tokens for abuse prevention. Facebook have hightighted a use case similar to the Cloudflare one. - Brave clients use a varient of Privacy Pass, as anonymous currency. Least Authority has a similar use case. ## Open discussion Dave Thaler: in slide 8, 1. do you see the scope of this BoF as web-context specific or more generic than web 2. What is the relationship between this problem and the problem of the RATS working group Alex: 1. web-only. It could be used elsewhere, but the focus would be web. 2. Not sure about RATS, don't know much about it. Dave: 2. it is closely related Ben Kaduk: agrees it looks closely related, worth looking at it. Brendan Moran: Are tokens transferable between clients? If not, how can you prevent that? If yes, what is this for? Alex: tokens are transferrable. Token does not provide metadata about how they were issued. Pete (or Brendan?): what is this protocol for? For testing whether human? What if it is handed to a bot? Alex: the intention is that these tokens are not collected on large scale. It is a trade-off between number of tokens, and the hope is that. Martin Thompson: you talk to an issuer and another entity who redeems the token. How much info tranverses this path, is there any possibility for the client to add info to this attestation? Alex: the protocol has more details on the architecture, how a client redeems it and forwards it to the checker. How it is handled depends on the HTTP API, the metadata included in there. Right now it is just some cryptographic collection of stuff. Subodh Iyengar: clarification of use cases: whether this is web-only/app? For Facebook it is more intended for the app rather than the web. For the fraud use case, it is an additional signal for use in anonymous logging. It is not only used as whether you are human or not, it is a high signal combined with other fraud-detection mechanisms. Daniel Migault: is the issued token from Cloudflare usable with Facebook for example? Alex: the current implementation requires the issuance server to match the validating server. Mariana Raykova: is the token some kind of credential, should the client guard it? She commented that it seems that it is the reposibility of the clients to guard the tokens Anthony Nadalin: Who do you see as issuer for these tokens? It could be a fraud issue. Do you expect a registry or something? Alex: Central authority, potentially some registry of issuers with cryptographic info. This is further covered on the architecture document. - Status of drafts/implementations, speaker: Steven Valdez - Slides (10 mins) - https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-ecosystem - Ecosystem, Key management, APIs - Open discussion (25 mins) Steven spoke around the architectural issues and an http API He also spoke around key management options: key rotation needs to be supported, and a way to audit the presentation fo keys The options can be 1. Issuer configuration (fetch from issuer), 2. proxied configuration fetching (clients will fetch from the proxy), 3. Commitment register (append to a append-only log, this needs to figure out the type of policies it will have) Open questions: an strategy for double spending, 2. detecting malicious servers, 3. key rotation windows 4. key management strategy ## Open discussion Ben Kaduk: Clarify around malicious server behavior Steven: for token issuer. A malicious server can try and learn indentifying information around clients: being able to invoke redemptions for many issuers. Subodh Iyengar: For double spending system, do all applications need perfect double spending? Steven: Not all will need it, but they will need to know the cost of not having it. It seems like not all applications need to be double spending secure. Richard Barnes: How critical this part of the work is? If the issuer is malicious, then maybe they will not apply it... Steven: this protocol is pretty privacy-tight. There are potential privacy effects, but browsers have been trying to tighten that. Dave Thaler: Why is double-spend an issue? They can have expiration, but why double spend? Steven: Only active for two weeks, so give 12 tokens. It indicates how much the user is trusted. It prevents malicious behavior. Dave: why only 12 tokens, not 12 minutes? Steven: this goes back to the transferrability thing. It is not bound to a user, and you don't want it to be used arbitrary many times across users. Dave: is it a workaround for lack of transferrability? Steven: partially yes. A user who is around for longer can be given more token. Dave: why does the number of tokens matter Steven: expirity is privacy-leaking, so this indeed is a workaround. Alex: client may not want to use the same token over and over again to avoid linkage between their uses. Mariana Raykova: a comment around the scope: she mentions that there is a protocol so the purpose of the WG should be further than what is already achieved by the protocol, and focus on the extensions. Steven: part of this WG is to make it a real protocol. It might be worthwhile expanding it beyond that. Georgio Nicolas: a question around if it is possible to generate a token from a previous token or if the protocol needs to be run from the start Steven: It is not possible, to avoid turning one into many tokens. Things built on top of privacy pass could potentially allow that. In general you would have to run the whole protocol. Ben Kaduk: got back to Dave Thaler's point, there seems to be a fundamental opposition between transferability and unlinkability: the token implies to be transferable and not tight to a client, so that is why double spending have to be in place. - WG Charter, speaker: Alex Davidson - Presentation (5 mins) - https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-charter - Charter revision and open discussion (40 mins) ## Open discussion (discussion prior to the charter slides) Ben Kaduk: maybe there is not much agreement in the use cases. Martin Thomson: relationship between the different actors, and how much trust do they need to give: as a client how much do I rely on the issuer not been malicious? More clarity around what the goals are. Steven: the client should trust the list of issuers, but not the individual issuer Martin: he highlighted the importance of it. Steven: yes, it need to be worked out in the application-specific documents. Joe Salowey: do people feel this is a topic for the IETF? Nick Doty: is there diversity in interest from implementors? If so, happy to review. If there are only a few companies, it might not be worth standardizing. Alex Davidson: We have several applications that will use it and we will find more. The current ones are limited to a few organizations, but it is preferrable to introduce more diversity. Eli-Shaoul Khedouri: we have a service called hCAPTCHA that uses Privacy Pass as well. We are not a larger company but we are interested. There will be more adoptions. Dave Thaler: I think the IETF should work on this problem (not necessarily this specific protocol), in relationship with RATS. Not yet conviced, but it will be useful the question of anonymity and transferability on a protocol dkg: I think the IETF should work on this. There are concerns around the centralization. Tommy Pauly: Apple is interested in this problem space. A good starting point. Watson Ladd: IETF should work on this. This solves a specific problem different than RATS. This is about anonymity: issue a token a redeem it later, without revealing information. Wendy Seltzer: IETF should work on this. There is interest from some W3C communities and she is happy to coordinate interactions with web APIs. Subodh Iyengar: IETF should work on this. They also have a use case for this. It is not a requirement of big companies. Anthony Nadalin: IETF should work on this. A concern of the sign-redepmetions records that can be used as authentication, so more security considerations should be put in the protocol. Joe Salowey: Who will contribute, either reviewing or implementing? Webex chat: a lot +1 +1 review: Christian (Huitema?) +1 review: Eli-Shaoul Khedouri, Intuition Machines +1 Review: Ais Connolly +1 (Review and contribute text, Joey S A19) +1 review, text, implement (for Cloudflare): Nick Sullivan, Sofía Celi +1 (not sure if review, implement or text): Armando Faz, Steven Valdez, Michele Orrù, Richard Barnes, Tancrède Lepoint, Anthony Nadalin, Mariana Raykova, dkg, Alex Davidson, Eric Kinnear, Yoav Nir, Subodh Iyengar, Tommy Pauly, Lucas Pardue, Jonathan Hoyland, David Schinazi, Wendy Seltzer, Ian Goldberg, frmichau, Martin Thomson, Yuji SUGA, Nick Doty, Sean Turner, Carrick Bartle, Marwan Fayed +1 (review): Vivek Arte Joe Salowey: Lots of interest. Not clear who is interested in reviewing or authoring. (continuation with slides) Alex: The charter lives on github. It was discussed at a side meeting on January. The main goals is to develop a protocol for the internet and web context for reedeming unforgeable tokens, which are also unlinkable (we had some feedback on how it interacts with transferability). The scope of the WG: three core documents (http API, maybe in contribution with W3C), analysis of the security and privacy concerns, commitment to develop interopable implementations (focus on the web context) Some open questions: 1. What are the milestones? The three core documents and some extensions 2. What are the policies for extensions? Ben Kaduk: two questions, 1. Are these three documents milestones? How strongly are we tied to these documents in slide 4 (Scope of WG), or can we break these down in others? Security and privacy analysis will be related to those milestones? Alex: The core documents were decided on the previous meeting. But these milestones are malleable: more or less documents can be put in place The privacy and security analysis are important but are covered on the architecture document. 2. Is it fundamental that a token gives an attribute? A issuer gives token for a single-attribute? Alex: It has been considered. Martin Thomson: I don't think this is a necessary property: clients and issuers can agree on information that carries accross in tokens. If issuers have to have a single property there can be privacy implications. There can be a loose of control of what information goes across. He wants to see further discussion around the relationship between entities. He is OK with the charter. The initial milestone can be to investigate around this. Alex: agrees on it. Andrew Campling: (on slide 4), will be analysis of privacy and security include considerations of the centralization problem Alex: Centralization around the issuers and a single entity. Not courrently considered; but it can be analysed. Joe: [...] Dave Thaler: What the charter should constrain the work around human tests? Should it be constraint to a web-context and where? Alex: It can be extended beyond human to client, but scoping to the web context Dave: Then the text should be clear to only web context. Christian Huitema: Like this work. There should be a point around centralization (of issuers) Alex: The concerns are valid, and can be added as an specific point. Eric Rescorla: Three points: 1. The availability of the client to verify the size of the anonymity 2. The use case requires more information 3. Clear analysis and a formal proof should be required. Alex: agree on the first point. On the 3 point: agree, needs to be put as a requirement. DKG: more bits means carved up anonymity sets (DKG via Jabber:) limiting the number of bits you can assert is a way to ensure that the issuer can only work with a single anonymity set. permitting arbitrary amounts of data works against the goal of a large anonymity set Alex: We should be careful about what. it is room for extra bits but have to be discussed in the draft. Subodh Iyengar: One of the use cases will be binding public information on these tokens. Make it work for campaing attribution. Consider extensions for the protocol. Mark McFadden: A concern about issuers: limited number of issuers: can it be prevented? Alex: Currently, is a open question raised by Steven. What we do is specified an append-only log that is necessary for issuers to give tokens. There should be a public audit mechanism to make sure clients are happy with it. It is intended for the architecture document. Mark: That is hopeful. The audit mechanism is difficult to imagine. It makes him worried about the whole process. Mariana Raykova (Google): A comment around the additional bits: if there a defined by client or issues, it will mean a particioning of the anonymity set. How do this map to the setting where there is multiple keys by the issuer? Alex: He agrees. Should be discussed, as there could be use cases that want this functionality. It will span the protocol and architecture. It is closely related to number of issuers and rotations Daniel Kahn Gillmor: onsolidation is a problem, and a serious one. This draft is talking about a mechanism that allows us to place some limits on consolidated information brokers. Alex: Agrees on this. It is clear that consolidation is missing from the charter, will be consider on the architecture. Auditing the centralized mechanism. Martin Thomson: Question: the nature of information that is passed and if clients know what it is (e.g. "is it a human?"). It is important for the client what information is carried, and how users will make the information transfer ans aware of that. Alex: interesting point. The thrid document is to define an API for browers: browers is making the decision on who to trust is an interesting question. The browers might give the option to unsubcribe. Martin: does not think that asking for forgiveness is the right approach. Not just who for, but what for. Alex: A valid point. It should be a discussion on the document or charter. [back to Joe for the last steps] Question for Ben and ?: Any other questions? More information necessary. Ben Kaduk: Quite a lof of value on the discussion. The proponents have a way to integrate the feedback and continue on the mailing list. Dave Thaler: Question around scoping and about the notion of transferability (cannot be prevented): should the charter scope this discussion as 'assuming that transferability cannot be prevent' or something similar? Alex: It needs to be discussed, maybe not in the charter, but says that the tokens should be unlinkable. It might belong more in the documention rather than a charter. Roman Danyliw: Follow up to Dave. It is worth talking about how it will be put on the document. It should be put in the charter: document the conclusion of the discussion. Stuart Card (sitting next to Adam Wiethuechter): The issue of non-transferability refers to the nature of authority. The client having an attribute is different to the client having the right to show that at some point had an attribute. If the holder of the token is the same guy that at some point in that past hold the attribute: then it needs to be addressed. Clarification by Stu of what I said: there is a difference between a token showing that I convinced an issuer that I had an attribute, and a token showing that I have a right granted to me (by the issuer) because I satisfied the issuer that I had that attribute; the former requires non-transferability, the latter in general does not; PS from our Jabber comments, we don't know whether non-transferability is compatible with unlinkability & unforgeability, but we think the issue must be addressed by the WG. Richard Barnes: This is good to be flagged as an issue. But not a hard requirement on the charter. EKR: Not sure how to define non-transferability. There should be a proposed definition. Ben Kaduk: Is this is a matter for IETF or as a research problem (IRTF) Alex: we have a protocol which we plan to use. Don't think the API will change substantially. It'd be good to get consensus on this. Ben: focus more on transferability. Alex: the transferability is inherant to the protocol design. Joe: Work up the charter details: rework the charter, discuss on the mailing list. ********************************************************************** Bluesheet - Sign with your name and affiliation The NOTE WELL statement applies to this meeting. Participants acknowledge that these attendance records will be made available to the public. ********************************************************************** Lucas Pardue, Cloudflare Olaf Kolkman, Internet Society Jim Schaad, August Cellars Daniel Kahn Gillmor, ACLU Ben Schwartz, Google Bernie Hoeneisen, pEp Foundation Robert Moskowitz, HTT Consulting Joe Salowey, Salesforce Stephen Farrell, Trinity College Dublin Sofía Celi, Cloudflare Eric Kinnear, Apple Alex Davidson, Cloudflare Valery Smyslov, ELVIS-PLUS Jonathan Hoyland, Cloudflare Cathy Aronson, ARIN Alissa Cooper, Cisco Tancrède Lepoint, Google Martin Thomson, Mozilla Eli-Shaoul Khedouri, Intuition Machines Drazen Urch, Intuition Machines John Kaippallimalil, Futurewei Shuai Zhao, Tencent tim costello, BT Ash Wilson, Valimail Dave Thaler, Microsoft Steven Fuerst, F5 Networks Yoshiro YONEYA, JPRS Adam Roach, Mozilla Brian Campbell, Ping Matthew Miller, Mozilla Colin Perkins, University of Glasgow Tommy Pauly, Apple Yasuo Okabe, Kyoto University Sean Turner, sn3rd Patrick McManus, Fastly Subir Das, Perspecta Labs Greg Wood, IETF LLC Mohamed Boucadair, Orange Steven Valdez, Google Frank Hartung, FH Aachen Warren Kumari, Google. John Border, Hughes Brian Haberman, Johns Hopkins University Carsten Bormann, TZI Michael Breuer, ilSF Alexey Melnikov, Isode Ltd chi-jiun su, hughes network systems Dan Druta, AT&T Scott Rose, NIST Ben Kaduk, Akamai Shumon Huque, Salesforce Jim Fenton, Altmode Networks Joseph Lorenzo Hall, Internet Society Ian Goldberg, University of Waterloo Adam Montville, Center for Internet Security Karen O'Donoghue, Internet Society Sam Weiler, W3C/MIT Mark McFadden, internet policy advisors ltd Ben Campbell, Independent Steffen Fries, Siemens Pete Resnick, Episteme Murray Kucherawy, Facebook Roman Danyliw, Carnegie Mellon University Éric Vyncke, Cisco Mark Baushke, Juniper Networks, Inc Melinda Shore, Fastly Michele Orrù, ENS and W3F Cullen Jennings, cisco Carrick Bartle, Apple George Kadianakis, Tor Project Mike Perry, Tor Project Dan McArdle, Google/Chrome Stephen Botzko, Poly Barry Leiba, FutureWei Deb Cooley, NSA Roland Jesske, Deutsche Telekom Chris Wood, independent Ted Hardie, Google Rich Salz, Akamai Ian Jacobs, W3C Peter Yee, AKAYLA Subodh Iyengar, Facebook Chen-Kuei Lee, Facebook Phil Hunt, IndependentId.com Nick Doty, UC Berkeley Rob Wilton, Cisco Hannah Davis, UCSD Peter Wu, Cloudflare Mohammed Khan,Cisco Monika Ermert, eLance Leif Sawyer, GCI Communications Brandon Maslen, Microsoft Simon Hicks, DCMS Grant Taylor, Self Rifaat Shekh-Yusef Dirk Balfanz, Google Martin Duke, F5 Networks Nick Sullivan, Cloudflare Russ Housley, Vigil Security LLC Sven-Erik Ceedigh, Agency for Digital Government, Sweden Yumi Sakemi, Lepidum Dan Harkins, HP Daniel Migault, Ericsson Chris Seal, CK Hutchison Hiroyuki Goto, Gree Linda Dunbar, Futurewei Dan York, Internet Society Joey Salazar, ARTICLE19 Ais Connolly, Ingenico Satoru Kanno, Lepidum Adam Wiethuechter, AX Enterprize, LLC† Karl Kathuria, Internews Shivan Sahib, Salesforce Emile Stephan, Orange John Mah, NortonLifeLock Brendan Moran, Arm Christian Huitema, Private Octopus Inc. Stuart Card, Critical Technologies, Inc. Jon Peterson, Neustar Kazunori Fujiwara, JPRS Spencer Dawkins, Tencent America Takahiro Nemoto, Tokyo University of Agriculture and Technology Wendy Seltzer, W3C Suhas Nandakumar, Cisco Mitsuaki Hatano Armando Faz, Cloudflare Yuji Suga, IIJ/CELLOS consortium Vivek Arte, UCSD Wes Hardaker, ISI Yoav Nir, Dell Allison Mankin, Salesforce Kristen Chapman, Salesforce Bhumip Khasnabish Leif Johansson, SUNET Andrew Campling, 419 Consulting Mark Nottingham, Fastly Kathleen Moriarty, Dell Technologies Marwan Fayed, Cloudflare Sofia Balicka, pEp Foundation Behcet Sarikaya, Self Frank Michaud, Cisco Nancy Cam-Winget, Cisco Xavier de Foy, Interdigital Richard Barnes, Cisco Chelsea Komlo, University of Waterloo Devon O'Brien, Google David Schinazi, Google Julien Maisonneuve, Nokia Hannes Tschofenig, Arm Watson Ladd, Cloudflare Stefan Santesson, IDsec Michael Montemurro, BlackBerry Eric Rescorla,Mozilla Mariana Raykova, Google Jari Arkko, Ericsson Sanjay Mishra,Verizon Mallory Knodel, CDT Andrew Campling, 419 Consulting