Re: [Privacy-pass] New drafts for IETF107

[Steven Valdez <[e-mail]>]

Some initial comments from trying to write the API doc against the
architecture doc:

- Having config_id and version seems like an odd set of names. config_id
appears to just be the ciphersuite being used in the protocol, and version
is the ID of the current set of key commitments.
- The supports field seems like it would always contain issue and redeem,
is there a use case where an set of keys would only ever be used for one or
the other?
- The revoked scheme seems a bit weird (modifying previous keysets after
the fact) and makes it hard to integrate with something like an append-only
log. Wouldn't it be easier to just use to have a set of fields at the top
level (under server_id) that list which keys are allowed to issue (always
the newest key) and redeem (the current and previous keys).


On Fri, Feb 21, 2020 at 12:15 PM Alex Davidson <adavidson=
[e-mail]> wrote:

> I’ve now pushed a WIP draft for the architecture
> document (draft-davidson-pp-architecture) to the same repo (
> https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts). There
> are a lot of TODOs still to address and I’m away for the next week, but I’m
> going to pick it back up when I return. Still aiming to have something
> submitted by the IETF 107 draft deadline on 9 March.
>
> The pp-protocol document is not currently very prescriptive about the data
> formats of each of the types that are sent in protocol messages etc. This
> is something that I am going to start addressing and, ideally, I’m going to
> rewrite to be consistent with the TLS presentation language [RFC8446
> <https://tools.ietf.org/html/rfc8446>] for compiling everything into
> standard formats (as it is also done in MLS,
> https://tools.ietf.org/html/draft-ietf-mls-protocol-08).
>
> Both drafts are still at a very early stage and so all feedback and
> contributions are very welcome (either here on the mailing list, or as
> GitHub issues/PRs are fine).
>
> Alex
>
> On 12 Feb 2020, at 17:35, Alex Davidson <[e-mail]> wrote:
>
> Hi all,
>
> I’ve taken an initial stab at a draft for the generic protocol overview at
> https://github.com/alxdavids/privacy-pass-ietf/blob/master/drafts/draft-davidson-pp-protocol/.
> I refactored out most of the stuff from the existing draft-privacy-pass
> doc. The biggest change is that I decided to go with a wrapper API around
> the VOPRF API for constructing the protocol. I then provide a specific
> implementation of this API using the VOPRF protocol. I think this will help
> when devising extensions to the protocol as it will enable others to
> either: modify the VOPRF API that is used, or to just modify the way that
> the PP API is implemented altogether (in situations that may not use
> VOPRFs, such as in the case of public verifiability).
>
> Some other things/questions to consider:
>
> - I avoided any of the discussions around the architecture required for
> maintaining client privacy, this includes how key rotation works. I decided
> that these considerations are beyond the scope of the generic protocol
> description, but happy to hear contrasting opinions?
> - The extension policy could probably do with some work. Since the privacy
> considerations will be in a separate document, currently I am assuming that
> any proposed extension satisfies the policies that will exist in each of
> the core three documents.
> - Is the proposed API suitable? Are there any concerns for potential
> extensions using this API?
> - I had to define some specific functionality for interacting with the
> groups used in the VOPRF implementation. Perhaps these can be moved to the
> VOPRF draft?
> - The provision of the security guarantees are lifted from
> https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf
> <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026..pdf>
>  and https://eprint.iacr.org/2020/072.pdf on the basis that the API
> implements the same protocol when using the VOPRF from
> draft-irtf-cfrg-voprf. This should probably be verified.
> - There are some minor TODOs that need to be fixed, such as links to
> non-existent drafts.
>
> I’ll start putting something together for the architecture document.
>
> Cheers,
> Alex
>
> On 6 Feb 2020, at 17:41, Alex Davidson <[e-mail]> wrote:
>
> Hi Steven,
>
> On 6 Feb 2020, at 15:22, Steven Valdez <
> svaldez=[e-mail]> wrote:
>
> Yeah, it makes sense not to wait for the BoF to start iterating on initial
> docs. Are you planning on putting the split document in a git repo
> somewhere? Might make sense to set up a repo with all the base drafts in
> one place as separate files (ala the QUIC WG) so that people can file
> issues/PRs.
>
>
> This is a good idea. I’ve repurposed the repo where I was hosting the
> draft charter previously to also include a space for working on the drafts
> here: https://github.com/alxdavids/privacy-pass-ietf/. I’ve placed the
> original draft-privacy-pass document in the drafts/ folder there, and we
> can use this space as a single location for contributing to these base
> drafts. Once a WG is formed, we can move this repo into a specific WG repo.
>
>
> I can take a stab at making a draft with a generic version of the
> integrations from the Trust Token API as a starting point for the third
> draft. I think fully specifying it will be dependent on the first two
> drafts, but having a starting point to feedback into laying out the earlier
> protocol/architecture descriptions would likely be useful for further
> iterating on those drafts.
>
>
> This would be helpful, thanks.
>
> Alex
>
>
> -Steven
>
> On Thu, Feb 6, 2020 at 7:31 AM Alex Davidson <adavidson=
> [e-mail] <[e-mail]>> wrote:
>
>> Since there has been no more feedback on the charter that was proposed, I
>> think that it may be useful to start work on drafting the three main
>> documents that make up the protocol specification. Having some initial
>> write-ups before the BoF @ IETF107 will also help to determine the agenda
>> for the meeting if there any initial issues that arise from the writing
>> process.
>>
>> These three documents should cover the following:
>>
>> - The generic description of the protocol, based on VOPRFs (or similar),
>> including specification of security considerations, protocol messages and a
>> framework for introducing extensions.
>> - The wider architecture for running the protocol: public interfaces, key
>> rotation, privacy goals, applications, analysis of tracking
>> potential/incentives for not following protocol.
>> - The API: specify how privacy pass data is integrated with HTTP
>> requests/responses, and where key material is stored/how it is accessed.
>>
>> Currently there is a single draft document (
>> https://datatracker.ietf.org/doc/draft-privacy-pass/) that includes
>> considerations mostly spanning from the first two documents (although it is
>> also includes some key management specifics). I can start to split this
>> document into two parts that could be used to initiate the process of
>> writing the initial drafts covering the first two points.
>>
>> The third point is not well specified as of yet, but there are some
>> applications such as the Trust Token API that integrate with HTTP already:
>> https://github.com/WICG/trust-token-api. Perhaps the third document
>> necessarily needs to succeed the first two? But if anyone would be willing
>> to start working on this document also, then that would be useful.
>>
>> Alex
>> --
>> Privacy-pass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>
>
> --
>
> Steven Valdez |  Chrome Privacy Sandbox |  [e-mail] |
> 210-692-4742 <(210)%20692-4742>
>
>
>
>
>

-- 

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