Re: [arch-d] Proposed IAB program on Wholistic Human-Oriented Discussions on Identity Systems (WHODIS)

Phillip Hallam-Baker <phill@hallambaker.com> Sun, 20 August 2023 19:39 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244B5C14CE40 for <architecture-discuss@ietfa.amsl.com>; Sun, 20 Aug 2023 12:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.409
X-Spam-Level:
X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkW72vGmPMXl for <architecture-discuss@ietfa.amsl.com>; Sun, 20 Aug 2023 12:39:28 -0700 (PDT)
Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0437C14CE36 for <architecture-discuss@ietf.org>; Sun, 20 Aug 2023 12:39:28 -0700 (PDT)
Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-1c504386374so1974581fac.3 for <architecture-discuss@ietf.org>; Sun, 20 Aug 2023 12:39:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692560368; x=1693165168; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MIlZXrYjqvBoTQYLtVvtWv4ko7fwPuxxFuvGW320E+w=; b=Q9oSylbV7mw0h4X7yqt1svsMi9tuvYheme3evGyiIHlNh7777j51gLXRY/Jfs2S7c5 S8XMhe3uYH5Y5WLrKearoGwzfjw48KpgSvx6WMjDkkdocPsHh7QQTHNrVxKc5o76p4Vs fsmGwxps6grjv/mXu320+KvyQNbvxoodRyqPyS/PEA1284JjDX2iCJEW/zIUKkpdp27V mJZEU9WpZyKf5bSch5XkZMCgTPgFfvbOnPDjbwiLU1ZMdBSuYhkYilAreTWgnq5bRKQZ j8VhBotB+lhAMZwSPGV0YD7CRGhnWoYGyvMlVrRZG1KhpjKsOVrKf8b0BJGrvZAdp4tO iAiw==
X-Gm-Message-State: AOJu0YzBXO9jSm2IaCcGbAHpDmtrUKHY3igUH4bq0rIMmy2nDSg09507 29bMySDOlfDmPGhpnHRfXucn61N3yzcJeZQrfbs=
X-Google-Smtp-Source: AGHT+IFLbwOv520KdAdRqWBrrCiM9ACP6MjhD4I97Udu48u094QuYmF0f8Z6c0Y59vb/5O4ZMrpZn19SBsi4Ped01pM=
X-Received: by 2002:a05:6870:ec90:b0:1c8:ca70:dd0c with SMTP id eo16-20020a056870ec9000b001c8ca70dd0cmr6869097oab.19.1692560367836; Sun, 20 Aug 2023 12:39:27 -0700 (PDT)
MIME-Version: 1.0
References: <f280e3ff-e498-47e8-aac5-1f320b47c827@betaapp.fastmail.com> <CADNypP_csCfe1W4ZMUhtQkurDKS+=FBDiGY7OaW4b37ipoKckQ@mail.gmail.com> <e553cc3e-5c3e-46e9-baf1-fe41af2e90c1@betaapp.fastmail.com> <CADNypP8WPOoPkFfn5o-dbRB50bXRT2yvhA6Y18RcrkRsJLb14w@mail.gmail.com> <4a2c5184-692b-4e2c-b1e8-7e480c60e897@betaapp.fastmail.com> <CADNypP9er0ThhjdKwWkEy7VbWh84icRciEhip=6X5WWS4icbmg@mail.gmail.com> <a0bc3442-94a7-47d0-901a-e9ed61c45a3e@betaapp.fastmail.com> <CADNypP-vUpfDQs0T1dwms1_kHpPR4ckkzea0KvmN8q_iAX7Q5A@mail.gmail.com> <ac2dd449-3a67-6aef-279f-62426be9c1a9@gmail.com> <CAMm+Lwjy34hofa+R4_KgVRZBv5y14c2R=HJ6kQNDsA0ZmrmWkg@mail.gmail.com> <ZOGZsubQNmjnkEtT@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZOGZsubQNmjnkEtT@faui48e.informatik.uni-erlangen.de>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 20 Aug 2023 15:39:13 -0400
Message-ID: <CAMm+Lwj4CbyF=b6OjyT2CjL96kSfdWrGLS=Uq94_5jqttA+kkQ@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Hesham ElBakoury <helbakoury@gmail.com>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007c607406035feb55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/JgHrMVg2tntDQQsrxaiJiNrFLtU>
Subject: Re: [arch-d] Proposed IAB program on Wholistic Human-Oriented Discussions on Identity Systems (WHODIS)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Aug 2023 19:39:29 -0000

On Sun, Aug 20, 2023 at 12:42 AM Toerless Eckert <tte@cs.fau.de> wrote:

> As long as we keep e.g.: corporate naming schemes such as eckert-<whatever>
> for all equipment assigned to me at some employer, i am sure that the
> trackers will be happy to have us develop hardly tracable user-identity
> for us as people.
>
> Translation: tongue in cheek example for how device identity/naming may
> undermine
> user identity, and that i fear such outcome will be more likely if we
> ignore it
> in the process we're about to engage in.
>

That strikes me as an anti-pattern for the reasons you suggest.

I have been trying very hard to avoid exposing device identifiers to
unauthorized parties. But that imposes some very real costs. Consider the
following scenarios which I think are all pretty good cases for identifying
a device:

* Any interaction with a device that has a static IP address on the public
Internet.
* Alice has 5 devices she uses to log into her employer's SSH systems.

Oh and yes, that first one pretty much busts a great big hole in the
argument IPv6 will make NAT go away. No it will not and it MUST NOT. The
only way to conceal which device I am using is to use some form of NAT.

There are also cases where I definitely don't want my specific device to be
identified. And for some of those I would ideally want to use threshold
techniques so that my phone, watch and laptop all have different shares to
the same signature key. I can prove which device signed a message but
nobody else can without the logs from my threshold service.