Subject: [Privacy-pass] Privacy Pass draft comments

From: Ben Schwartz <[email-masked]>
Date: Fri, 24 Jul 2020 17:43:22 -0400

Some comments on the drafts scheduled for discussion in our session next
week:

On the architecture:
The draft mentions a use case for "1 bit of metadata" without further
explanation.  Is this in reference to the PMBToken proposal?  I think it
would be worth clarifying the reference.

Regarding PMBToken, I'm not sure that proposal necessarily reduces the
anonymity set in the way that the architecture draft describes.  It sounds
like the server returns either a valid token, which the server can later
verify, or an invalid token, which the server cannot distinguish from
client-generated garbage.  If so, we might avoid reduction of client
anonymity by encouraging all clients to attempt to send garbage tokens
occasionally.  "Don't Take Any Wooden Nickels" [1].

On the HTTP API:
There's no explanation of why this is all being jammed into a
Sec-Privacy-Pass header.  This is very much unlike a typical REST API.
What's the goal here?  I think it would be worth clarifying.

If this design is to allow tacking redemptions onto arbitrary HTTP requests
like a cookie, then could issuance still be a normal REST API?  Then we
probably wouldn't need the "type" field for redemption; it could be
implicit.

--Ben

[1] https://en.wiktionary.org/wiki/don%27t_take_any_wooden_nickels

---

From: Steven Valdez <[email-masked]>
Date: Fri, 24 Jul 2020 18:03:50 -0400

In terms of the bit of metadata, in the current drafts it's not currently
tied to a specific proposal and doesn't have a protocol to support it, but
one potential way to support it is building on top of the PMBToken
primitive which provides the one bit of metadata property. Unless I'm
looking at the wrong section, it currently uses a bit of metadata as an
example of the privacy considerations that metadata introduces.

(As for the specific PMBToken case, it lets an issuer set a token to be one
of two values, that are both cryptographically signed. I think the one
you're looking at is the other construction for a PrivacyPass token without
the ZKPs?)

---

For the HTTP API, one open question (short list in the presentation for
108), includes whether the API recommended in the WG document should be
tied to .well-known endpoints or if we should generalize it to allow the
issuer to provide the capabilities on top of any endpoint. But yes, the
current draft has a foot in both worlds, and once we resolve that question
either moving it to a REST API on the well-known or omitting the well known
entirely is probably the right move.

Keeping it at .well-known would mean doing something like:

https://captcha.example/submit-challenge-answer (sets state with the result
of the challenge).
https://captcha.example/.well-known/privacy-pass (Does the actual issuance
via PrivacyPass)

Potentially a server might want something like:

https://captcha.example/submit-challenge-answer and if the client attaches
an issuance request in the Sec-Privacy-Pass header, the response could
return PrivacyPass tokens directly.

On Fri, Jul 24, 2020 at 5:43 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> If this design is to allow tacking redemptions onto arbitrary HTTP
> requests like a cookie, then could issuance still be a normal REST API?
> Then we probably wouldn't need the "type" field for redemption; it could be
> implicit.
>
> --Ben
>
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

-- 

Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
 210-692-4742

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 24 Jul 2020 20:56:52 -0400

I'm referring to Section 9.1:

>   In terms of additional metadata, the only concrete applications of
>   Privacy Pass that use additional metadata require just a single bit.

There's no mention of what concrete applications these might be.

> you're looking at is the other construction for a PrivacyPass token without

Thanks, I was looking at an intermediate construction in the PMB paper.

> entirely is probably the right move.

Sounds good.  I'm sure we can figure that out.

> https://captcha.example/submit-challenge-answer (sets state with the
> result of the challenge).
> https://captcha.example/.well-known/privacy-pass (Does the actual
> issuance via PrivacyPass)
>
> https://captcha.example/submit-challenge-answer and if the client
> attaches an issuance request in the Sec-Privacy-Pass header, the response
> could return PrivacyPass tokens directly.
>
>> would be worth clarifying the reference..
>>
> 210-692-4742 <(210)%20692-4742>
>