Re: [Pearg] IP address Privacy Interim Follow up - Reputation System

Matthew Finkel <sysrqb@torproject.org> Wed, 27 January 2021 03:32 UTC

Return-Path: <sysrqb@torproject.org>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECD73A118C for <pearg@ietfa.amsl.com>; Tue, 26 Jan 2021 19:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWAXZIxjQ_ct for <pearg@ietfa.amsl.com>; Tue, 26 Jan 2021 19:32:05 -0800 (PST)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B8F3A118B for <pearg@irtf.org>; Tue, 26 Jan 2021 19:32:04 -0800 (PST)
Received: from fews1.riseup.net (unknown [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4DQTfm0MDyzFmM6; Tue, 26 Jan 2021 19:31:44 -0800 (PST)
X-Riseup-User-ID: 045E39E5B9A1C7AA02E702606C7FAC40950A79E8CEDA3D057F36A8790E37E771
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DQTfY36kpz5wFJ; Tue, 26 Jan 2021 19:31:32 -0800 (PST)
Date: Wed, 27 Jan 2021 03:31:20 +0000
From: Matthew Finkel <sysrqb@torproject.org>
To: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Cc: pearg@irtf.org
Message-ID: <20210127033120.6kwbu37jfgrwz7fg@localhost>
References: <20210121153816.lri4s3iqpjsh3plo@localhost> <CAG3f7MjROSoH_Hx26Mpov6b8n85-q7-8a22xdbxZ-8B+8kviug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAG3f7MjROSoH_Hx26Mpov6b8n85-q7-8a22xdbxZ-8B+8kviug@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/PtzfJYIkUfEZZEIuBLclA9yPxIw>
Subject: Re: [Pearg] IP address Privacy Interim Follow up - Reputation System
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2021 03:32:07 -0000

Hi Shivan,

Thanks for this guidance. I haven't followed the PrivacyPass
standardization effort since early last year, so I'll review that before
starting on an I-D. I'll reply here if the new PrivacyPass protocol does
not seem appropriate for this use case, and I'll appreciate
collaborating with someone who works on the service-side and knows the
challenges there.

On Tue, Jan 26, 2021 at 04:23:08PM -0800, Shivan Kaul Sahib wrote:
> Hi Matt, the Privacy Pass protocol being standardized at the IETF has
> similar use cases: https://datatracker.ietf.org/wg/privacypass/documents. A
> good way to drive discussion is to put together an Internet Draft that
> folks can review and comment on!
> 
> On Thu, Jan 21, 2021 at 7:38 AM Matthew Finkel <sysrqb@torproject.org>
> wrote:
> 
> > Hi Everyone,
> >
> > I'd like to follow up on the topic of reputation systems we briefly
> > touched on Tuesday. I'd like to understand the criteria of a system that
> > can help the Internet move towards deprecating IP addresses as a
> > fundamental signal in account-security/anti-fraud/anti-abuse systems.
> >
> > >From the perspective of a web user agent, I'll start with the following
> > properties:
> >
> >   - A reputation and its associated identity must not be linkable
> >     - This excludes the user and, possibly, a "reputation provider"
> >   - A reputation must not be universally unique
> >     - I suggest bucketing reputation into ~5 sets
> >   - A reputation must not be a tracking vector
> >     - Two "proofs of reputation" must not be linkable, neither across
> >       sites nor on the same site.
> >   - A client must be able to know (or query) its recent reputation
> >   - A service provider must be able to increase and decrease a
> >     reputation
> >   - A client must only use a recent reputation
> >     - A reputation should become stale and invalid within a short period
> >       of time
> >   - A client must be able to audit its reputation
> >   - A client must be able to dispute changes in its reputation
> >   - transitioning from a "bad" reputation to a "good" reputation should
> >     be reasonably possible
> >   - Computing a reputation must be well defined
> >   - The system must support "anonymous" identities
> >     - A client must be able to create a new and unique reputation not
> >       linkable to previous reputations or identities
> >   - A reputation must not be influenced by an associated IP address
> >
> > While these are not all hard requirements, it is important that this
> > system doesn't become a "virtual credit bureau" where someone's
> > reputation is based on black magic and good fortune.
> >
> > As a meta comment, I'm relatively new to IETF/IRTF processes, so I
> > appreciate recommendations on how this discussion should proceed.
> >
> > Thanks,
> > Matt
> >
> > --
> > Pearg mailing list
> > Pearg@irtf.org
> > https://www.irtf.org/mailman/listinfo/pearg
> >