Re: [Privacy-pass] Question on proposed charter

I found the new unlinkability text somewhat confusing, so I proposed a slight variant in the following PR (along with a couple other nits). With or without this PR, this looks good to go!

   https://github.com/alxdavids/privacy-pass-ietf/pull/28

Best,
Chris

On Wed, May 20, 2020, at 1:28 AM, Alex Davidson wrote:
> Great, I’ve merged it.
> 
> > On 20 May 2020, at 04:58, Joseph Salowey <joe@salowey.net> wrote:
> > 
> > Good, I think we should merge the change. 
> > 
> > On Tue, May 19, 2020 at 5:43 PM Ben Schwartz <bemasc@google.com> wrote:
> >> Thanks. With those changes I think this is ready to go.
> >> 
> >> On Tue, May 19, 2020 at 5:16 AM Alex Davidson <adavidson=40cloudflare.com@dmarc.ietf.org> wrote:
> >>> Hi all,
> >>> 
> >>>> "Negotiation of cryptographic parameters during the protocol is an application-specific property and thus out of scope for the Working Group."
> >>>> 
> >>>> What are the cryptographic parameters and why would they not need to be negotiated for interoperability?
> >>>> 
> >>>> Also, is the following text a result of the algorithms being worked on in CFRG vs. this working group?
> >>>> 
> >>>> I suspect this would be things like the curves and configuration used for the underlying crypto primitives. I think the idea is that the core PrivacyPass protocol wouldn't support any sort of negotiation, and the applications built on top of PrivacyPass would either specify the properties in their implementation or provide their own negotiation mechanism (for example an HTTP application might have the curves it supports hard-coded based on what the relevant clients/servers want to support for compatibility or have some HTTP-application-layer mechanism to choose corresponding server configurations..
> >>>> 
> >>>> Though it might be worth specifying at the PrivacyPass layer what the actual "acceptable" combination of parameters is to maintain security/privacy properties.
> >>> 
> >>> So I think the core of the matter here is that the ciphersuite is chosen by the Issuer ahead of time, and it is assumed that the client can retrieve this information apriori. So we can change this to: "The cryptographic profile used by the protocol participants will be determined by the specific instantiation of the protocol, and it will be chosen ahead of time.”
> >>> 
> >>>> 
> >>>> "Specification of the underlying cryptographic algorithms or protocols is also out of scope."
> >>>> 
> >>>> If so we might mention that this work depends on the work in the CFRG. 
> >>> 
> >>> I agree, perhaps we could replace this with: "We will work closely with the CFRG to determine acceptable cryptographic ciphersuites and parameters that satisfy the security/privacy properties of the protocol” to follow on from the sentence above?
> >>> 
> >>> Additional changes:
> >>> 
> >>> It was brought up off-list by Ben Schwartz that using the term “unlinkability” in the charter may lead to confusion, so I have replaced: 
> >>> 
> >>> "Any token granted by a given Issuer is unlinkable with all other
> >>> tokens granted by the same Issuer.”
> >>> 
> >>> With:
> >>> 
> >>> "Any token granted by a given Issuer is indistinguishable from all
> >>> other tokens granted by the same Issuer key at redemption
> >>> time.”
> >>> 
> >>> I’ve created a new PR with these proposed changes: https://github.com/alxdavids/privacy-pass-ietf/pull/27.
> >>> 
> >>> Cheers,
> >>> Alex
> >>> -- 
> >>>  Privacy-pass mailing list
> >>> Privacy-pass@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/privacy-pass
> 
> -- 
> Privacy-pass mailing list
> Privacy-pass@ietf.org
> https://www.ietf.org/mailman/listinfo/privacy-pass
>