Re: [Privacy-pass] Privacy Pass extensions

[Nick Doty <[e-mail]>]

Thanks for considering this question directly and fleshing out some
privacy considerations for an example of additional metadata for a
privacypass extension. Apologies in advance that I haven't understood
all the text or design decisions.

I don't think I follow how the expiration metadata is to be selected
in this case. Perhaps that's just application-specific, but it makes
it harder to evaluate the privacy implications. Presumably the origin
has some policy that it communicates to the client and the client uses
that to select the expiration time that it requests tokens for: is
that right? (Otherwise, the client would just request tokens that
expire in the distant future.) But how the origin communicates this
policy to the client would appear to affect how distinguishing the
information is. An origin might communicate different policies to
different clients, or might choose a narrow policy that makes it
harder to choose consistent timestamps shared by many other clients.

The possible mitigations described (though none would be required,
everything would be application and implementation-specific) are
focused on promoting consistency between clients. So I won't show up
as uniquely identifying if there are other clients that also selected
the same expiration timestamp. But the expiration timestamp won't be
the only distinguishing piece of information about me, it will be
combined with other details about my behavior and client
configuration. Even if there was an enforcement that at least k other
clients used the same expiration timestamp that I did (one possible
mitigation forseen by this draft, although not required), those other
k clients likely won't be the ones accessing the service from Durham,
North Carolina or using my User-Agent.

These considerations will vary by application, of course. In the Web
context, I would anticipate that this would be adopted primarily for
browser fingerprinting: in addition to whatever other entropy gathered
about the client, the origin can add how many minutes past the hour
(or which hour of the day, or...) is the expiration timestamp, etc. It
would also make it less safe to cache tokens across clearing of local
state (clearing cookies).

While linkability between attester and origin contexts is always a
risk if parties are trying to collude, the extra metadata of
expiration time would seem to make it much easier to accomplish; even
if tokens are cached for a long time, the origin can help narrow it
down extensively by adding the extra detail about expiration time (as
well as IP address, etc.).

One mitigation might be ensuring that every client that accesses an
origin at time T to have the same expiration timestamp T+X, so that
the metadata provides no additional information to the origin. This
would seem to require standardizing how the expiration policy is
communicated and to provide consistency checks to ensure that that
policy is consistently provided to all clients. That would be easier
to evaluate, and would lend itself to normative requirements in the
extension spec to ensure that that condition was met.

Cheers,
Nick

On Mon, Aug 7, 2023 at 5:16 PM Christopher Wood <[e-mail]> wrote:
>
> Hi folks,
>
> During last week's meeting we spent some time discussing extensions to Privacy Pass [1]. One of the concerns raised -- rightfully so! -- was the need to clearly articulate the privacy implications of using any sort of metadata, as well as mitigations to deal with any possible privacy regressions.
>
> As most here probably know, the architecture document does attempt to provide some general considerations for token types that include metadata [2]. Certainly, the exact implications depend on the extension in use -- an extension which encodes the IP address of the client is a lot different than one which encodes a single bit key epoch. I think it's clear that any work on extensions need to have a well understood privacy story that's clearly documented before publication.
>
> In the interest of making forward progress, we updated the expiration extension draft to provide (what we feel are) reasonably clear guidance. You can view the diff at [3], and the full version at [4].
>
> At this point, we'd like to understand if this split in guidance strikes the right balance for the group's work on extensions. In particular, does this text -- when combined with what's currently in the architecture document -- provide adequate guidance for implementers and other relevant deployment stakeholders? If not, what is missing, and where is it missing?
>
> Thanks,
> Chris, for the editors
>
> [1] https://datatracker.ietf.org/doc/slides-117-privacypass-proposed-extensions-to-privacy-pass/
> [2] https://ietf-wg-privacypass.github.io/base-drafts/draft-ietf-privacypass-architecture.html#name-partitioning-by-issuance-me
> [3] https://author-tools.ietf.org/iddiff?url1=draft-hendrickson-privacypass-expiration-extension-00&url2=draft-hendrickson-privacypass-expiration-extension-01&difftype=--html
> [4] https://datatracker.ietf.org/doc/html/draft-hendrickson-privacypass-expiration-extension-01
>
> --
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass