Re: [Privacy-pass] New drafts for IETF107

[Alex Davidson <[e-mail]>]

Just as an update, we now have initial drafts for all of the three proposed documents at https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts/ <https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts/> (protocol, architecture, http-api contributed by Steven). We will be submitting these as individual drafts before the 09 March deadline to be discussed at the BoF. Any feedback is welcome!

> On 2 Mar 2020, at 14:28, Steven Valdez <svaldez=[e-mail]> wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 6:57 AM Alex Davidson <adavidson=[e-mail] <mailto:[e-mail]>> wrote:
> Hi Steven,
> 
> Thanks for the feedback.
> 
>> On 26 Feb 2020, at 15:22, Steven Valdez <svaldez=[e-mail] <mailto:svaldez=[e-mail]>> wrote:
>> 
>> 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.
> 
> You’re right, perhaps ciphersuite and commitment_id would be better?
> This seems reasonable naming. 
> 
>> - 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?
> 
> This is true, I was mainly leaving this open in case there were extensions that split the server functionality. For example, if we go down the public verifiability route, then it would be conceivable that only “redeem” would be supported?
> I assume you mean only "issue" in the public verifiability case?  But seems reasonable for extensibility.
> 
>> - 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).
> 
> I agree with this change, I’ll adopt this in a new version of the draft.
> 
>>  
>> 
>> On Fri, Feb 21, 2020 at 12:15 PM Alex Davidson <adavidson=[e-mail] <mailto:[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 <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 <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] <mailto:[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/ <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 <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] <mailto:adavidson@cloudflare..com>> wrote:
>>>> 
>>>> Hi Steven,
>>>> 
>>>>> On 6 Feb 2020, at 15:22, Steven Valdez <svaldez=[e-mail] <mailto: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/ <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] <mailto:[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/ <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 <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] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>
>>>>> 
>>>>> 
>>>>> -- 
>>>>> 
>>>>> Steven Valdez |	 Chrome Privacy Sandbox |	 [e-mail] <mailto:[e-mail]> |	 210-692-4742 <tel:(210)%20692-4742>
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> Steven Valdez |	 Chrome Privacy Sandbox |	 [e-mail] <mailto:[e-mail]> |	 210-692-4742 <tel:(210)%20692-4742>
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [e-mail] <mailto:[e-mail]> |	 210-692-4742