Re: [Privacy-pass] New drafts for IETF107

Hi Sofia,

Thanks for taking the time to read through the drafts.

> On 24 Mar 2020, at 06:55, Sofía Celi <cherenkov@riseup.net> wrote:
> 
> Hi, Alex!
> 
> Thanks so much for sending this!
> 
> I have some points after reviewing the documents. I'll first send the
> notes for the draft of the protocol, as I have to put my notes for the
> other ones in place ;)
> 
> The first thing I noticed is that there should be consistency with the
> naming of variables:
> 
> - Sometimes a server is referred as 'server', while other times as
> 'Privacy Pass server'. I think the document always refers to a Privacy
> Pass server; but a reader might think there are two kinds of servers.
> The same for when using 'client' and 'Privacy Pass Client'.
> - Most of the inside values of the defined structs have a
> larger/meaningful name.. so maybe 'ServerUpdate s', should change to
> something else.
> - The struct 'ClientIssuanceInput' has a 'ClientIssuanceProcessing
> client_data' value, which holds inside a 'opaque
> client_data<1..2^32-1>', maybe it will be good to change the name of the
> inside 'client_data', as it can become confused with the external one.
> - I was thinking that maybe all of the structs should be named according
> to who deals with them as 'ClientIssuanceInput' or 'ServerUpdate'. This
> can be applied to 'IssuanceResponse' or 'IssuanceMessage'.
> - Some variables change names, like 'cfg', which can be also 'srv_cfg'
> or 'cli_cfg'. Maybe they should always be called in the right places
> 'srv_cfg' and 'cli_cfg'.
> - There is other naming consistency issues that I can fix on a PR. But
> the idea was to be consistent on them ;)
> 
> - The definition 'Commitment' is defined but never used in the document.

The points that you’ve raised above all make sense to me. If you would be interested in submitting an issue/PR for solving them, that would be really useful and I would be happy to review it.

> 
> - On this section:
> """
> * At any one time, we assume that the Server uses only one
> configuration containing their ciphersuite choice along with their
> secret key data.
> * We assume that the client has access to a global directory of the
> current configurations used by all Privacy Pass servers.
> """
> It seems to imply that the client have access to the configuration which
> includes the ciphersuite and server secrets.. Maybe here it will be good
> to clarify that clients only have access to the public part of the
> configuration of servers.
> 
> - The document should probably clarify that it will only refer to
> communication between one server and a client. It should also probably
> state that the handling of different clients and servers is the
> responsibility of the architecture document. I was think maybe a section
> with the limitations/out-of-scope of the draft, and where on the other
> drafts they are addressed.

Both of the above clarifications make sense to me. In particular, specifically laying out the scope of the draft is something that we should definitely do to avoid confusion.

> 
> - The architecture draft states the possibility of the existence of
> malicious servers that can rotate keys in a short time frame. Something
> that maybe also needs to be think about is the possibility of malicious
> servers deleting the storage of valid inputs (used to protect against
> double spending). I don't know how possible this can be, and how to
> protect.. but I was just wondering if it has been thought.

I guess this is a possibility. However, a server should only really maintain the double-spend index for their own security (to prevent clients from spending the same token over and over again). If a server decides to delete this storage, then really they have only harmed themselves. So I’m not sure if we need to cover this point specifically, other than mentioning that the server SHOULD maintain a double-spend index as detailed in the document.

> 
> I can create issues for these points and send some PRs on them, so let
> me know if you agree on them ;)

Sure! Documenting the consistency and clarification points on the GitHub repo would be useful.

Thanks,
Alex

> 
> Thanks!
> 
> 
> 
> -- 
> Sofía Celi
> @claucece
> Cryptographic research and implementation at many places
> FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02
> 
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass