Re: [Privacy-pass] Follow-up: Privacy Pass RWC meeting

[Steven Valdez <[e-mail]>]

For the most part the charter looks reasonable.

One thing worth figuring out is if extensions to the protocol outside of
the main documents are in-scope for the working group The charter talks
about setting up a framework for supporting extensions, but is working on
other documents describing these extensions part of the WG or should they
be done as independent drafts/their own workstream?



On Tue, Jan 21, 2020 at 7:32 AM Alex Davidson <adavidson=
[e-mail]> wrote:

> Hi all,
>
> Just wanted to follow up on accumulating feedback for the charter again.
> It’s important that we agree on this since it is necessary to have before
> we can proceed with organising a BoF meeting @ the IETF.
> Let us know if you have any comments on what is currently written.
>
> I’m going to move the discussion surrounding the previous agenda items and
> the next steps for the BoF process to separate threads.
>
> Cheers,
> Alex
>
> On 10 Jan 2020, at 17:26, Alex Davidson <[e-mail]> wrote:
>
> Hi all,
>
> Thanks to everyone who managed to attend yesterday and contribute to the
> interesting discussion! We did not quite manage to finish walking through
> the draft charter and there were also some agenda items that we did not
> manage to discuss.
>
> With this in mind, perhaps a good way to move forward would be the
> following:
>
> - I have attached the current iteration of the charter to this email and I
> have also created a GitHub repository containing it at
> https://github.com/alxdavids/privacy-pass-wg-charter. We can iterate on
> the charter on list, or using PRs & issues in the GitHub repo.
> - We arrange another side-meeting (probably virtual) between now and the
> time of IETF 107 (21-27 Mar, Vancouver) to discuss the rest of the agenda,
> which is:
> - Next steps for the BoF process and IETF107
> - Discussion of use-cases
> - Agreement on protocol extensions
> - If anyone would like to raise anything separately then we can discuss it
> on this list.
>
> If we go ahead with the side-meeting, we should aim to have something
> close to a stable charter. This would allow us to focus on how to move the
> BoF process forward.
>
> Best,
> Alex
>
> Note: I’ve cleaned up the draft a bit based on the notes that were made
> during the meeting.
>
> ==== BEGIN CHARTER ====
>
> The Privacy Pass protocol was first proposed in November 2017 as a
> performant mechanism for providing privacy-preserving attestation of a
> previous successful authorization between a human and a server.
>
> The primary purpose of the Privacy Pass working group is to develop and
> standardize the protocol, influenced by applications that have arisen from
> the wider community. The main requirements of the working group are to
> develop a protocol that satisfies the following properties:
>
>
>    - Issued tokens are unlinkable with other tokens corresponding to the
>    same anonymity set.
>    - Tokens are unforgeable.
>    - The issuance and verification mechanisms are practically efficient.
>
>
> The aims of the working group can be split into three distinct goals that
> we describe below.
>
> 1) Develop the specification of the generic protocol:
>
>
>    - Specify the full cryptographic authorization exchange and
>    terminology along with suitable ciphersuites (and security
>    parametrizations) for maintaining security for a meaningful time period.
>    - The negotiation of ciphersuites is determined by the
>       application-specific profile and out-of-scope for this protocol.
>       - Describe the structure of protocol messages.
>    - Describe a framework for extensions to the base protocol for
>    achieving additional functionality, or for providing different security
>    guarantees.
>
>
> 2) Develop the wider architecture for running the protocol
>
>    - Construct interfaces that make the protocol suitable for integration
>    with potential use-cases.
>    - Including required functions for applications
>       - Document potential applications of the protocol and of its
>    official extensions
>    - Define the privacy goals for each client during the exchange, along
>    with expectations placed on the server and the ecosystem at large.
>    - Analyse mechanisms for tracking via public key and expectations
>       placed on server.
>       - Privacy considerations of incentives for not verifying messages
>       correctly (along with general threat model).
>
>
> 3) Develop document for Privacy Pass in HTTP?
>
>    - Specify a common understanding of how Privacy Pass data is
>    integrated with HTTP requests and responses for web-based applications.
>
>
>    - Specify where key material stored, how it’s accessed, and associated
>    security considerations
>
>
>
> Each goal listed above will be fulfilled with an individual document that
> addresses the necessary conditions. Once these documents are completed,
> this working group will have concretized a standardized architecture for
> constructing instances of the protocol. As a consequence, this will enable
> an ecosystem of applications that depend on the authorization framework
> provided by Privacy Pass.
>
> In particular, by the time that the working group achieves consensus
> around these documents, we hope to have a number of interoperable
> implementations, a clear analysis of the security and privacy
> considerations, and a diverse ecosystem of concrete applications.
>
> Note that the specifications developed by this working group will be
> informed by draft-irtf-cfrg-voprf
> <https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/> which is
> currently owned by the Crypto Forum Research Group (CFRG@IRTF). In
> addition, draft-privacy-pass
> <https://datatracker.ietf.org/doc/draft-privacy-pass/> will serve as a
> starting point for the work of the working group.
>
> ==== END CHARTER ====
>
>
>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>


-- 

Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
 210-692-4742