Minutes IETF107: privacypass
minutes-107-privacypass-00

**********************************************************************
          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