Subject: [Privacy-pass] Question on proposed charter

From: Joseph Salowey <[email-masked]>
Date: Sun, 17 May 2020 15:11:53 -0700

There are a few questions on the proposed charter:

In the text

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

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

Thanks,

Joe

---

From: Steven Valdez <[email-masked]>
Date: Mon, 18 May 2020 11:02:31 -0400

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

> Thanks,
>
> Joe
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

---

From: Alex Davidson <[email-masked]>
Date: Tue, 19 May 2020 10:15:46 +0100

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

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 <https://github.com/alxdavids/privacy-pass-ietf/pull/27>.

Cheers,
Alex

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 May 2020 20:43:28 -0400

Thanks.  With those changes I think this is ready to go.

On Tue, May 19, 2020 at 5:16 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> choose corresponding server configurations..
>
> 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.”
>
>
> 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:
>
> I’ve created a new PR with these proposed changes:
> https://github.com/alxdavids/privacy-pass-ietf/pull/27.
>
> Cheers,
> Alex
> --

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 19 May 2020 20:58:05 -0700

Good, I think we should merge the change.

---

From: Alex Davidson <[email-masked]>
Date: Wed, 20 May 2020 09:28:49 +0100

Great, I’ve merged it.

> On 20 May 2020, at 04:58, Joseph Salowey <[email-masked]> wrote:
> 
> On Tue, May 19, 2020 at 5:43 PM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, May 19, 2020 at 5:16 AM Alex Davidson <adavidson=[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 20 May 2020 12:02:24 -0700

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:
> >> On Tue, May 19, 2020 at 5:16 AM Alex Davidson <adavidson=[email-masked]> wrote:
> >>> Hi all,
> >>> 
> >>> I’ve created a new PR with these proposed changes: https://github.com/alxdavids/privacy-pass-ietf/pull/27.
> >>> 
> >>> Cheers,
> >>> Alex
> >>> --