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

Matthew Finkel <sysrqb@torproject.org> Thu, 21 January 2021 15:38 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 E47D93A0D81 for <pearg@ietfa.amsl.com>; Thu, 21 Jan 2021 07:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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 ioKhVT0uTeIo for <pearg@ietfa.amsl.com>; Thu, 21 Jan 2021 07:38:39 -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 7C0633A10FE for <pearg@irtf.org>; Thu, 21 Jan 2021 07:38:38 -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 4DM6490x6PzFs59 for <pearg@irtf.org>; Thu, 21 Jan 2021 07:38:33 -0800 (PST)
X-Riseup-User-ID: 5FC13EAFDBD8F4618B04BF41A8480F54B2A340A047EDA28298A85872CB1BAD2C
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4DM6476N4Pz5xfk for <pearg@irtf.org>; Thu, 21 Jan 2021 07:38:26 -0800 (PST)
Date: Thu, 21 Jan 2021 15:38:16 +0000
From: Matthew Finkel <sysrqb@torproject.org>
To: pearg@irtf.org
Message-ID: <20210121153816.lri4s3iqpjsh3plo@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/YbWZe6FtNMh9KkQrLMM3-dzbtjA>
Subject: [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: Thu, 21 Jan 2021 15:38:41 -0000

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