Re: [Privacy-pass] New drafts for IETF107

[Steven Valdez <[e-mail]>]

On Mon, Mar 2, 2020 at 6:57 AM Alex Davidson <adavidson=
[e-mail]> wrote:

> Hi Steven,
>
> Thanks for the feedback.
>
> On 26 Feb 2020, at 15:22, Steven Valdez <
> 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]> 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 <(210)%20692-4742>
>
>
>

-- 

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