Re: [Privacy-pass] Question on proposed charter

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
>>
>