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

Phillip Hallam-Baker <> Sun, 20 August 2023 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A66CCC151066 for <>; Sun, 20 Aug 2023 13:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Status: No, score=-1.405 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u-fmCAHQensm for <>; Sun, 20 Aug 2023 13:44:30 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 075D5C151063 for <>; Sun, 20 Aug 2023 13:44:29 -0700 (PDT)
Received: by with SMTP id 46e09a7af769-6bd0c953fd9so1766134a34.3 for <>; Sun, 20 Aug 2023 13:44:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1692564269; x=1693169069; 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=kIS4SpHcTUStf3PZ7RBG3DbmUw+VULoWIi+Y7B9rq5s=; b=AfZeft9fQqDMr18NMqbYKqU0XbGJjqFLau8xDzIFLDIegem3ECias2qPIsz2TmlXct cKUogguPBozhh8bGYnbvfVVmYMc8ELLxh7TW2eTpAbBx116f0rhg+wO8MO2KArGNUubl a075/oUxwcbk0unK4TYuqKlRxgeBlKHTR8sockCoCREVLyU5zz760njzdBhnXLUUzsAu lWqrdakInPuI7OZQZKSOwetqXkRZkK2hH/GYEz/UscG8LXF9+Sfu5hdEF1GEIwIJdGlF YsB9d1vqYJG3OJWO5Z721kfla1vQhL3qhGFnm1XpRAsHXVRALrLkuF54hEY2IqHNjZuW J6Wg==
X-Gm-Message-State: AOJu0YztNTBJct2EE5likoOhjeShAQZMPIjUu+xsGCVWjWdOui5kttt/ 61hI9mQsPaYcyC7m7gR3l/anWlXR25ocXBfp3xr8JwUQ
X-Google-Smtp-Source: AGHT+IHOEjQdhXlQ32OOX6IEFG0sl+GXQenuUH5oDBnjeVl65937xx4rK9WokxMZAFdqtRPo0HuO3HtXkAz43AfxW1A=
X-Received: by 2002:a05:6870:15c1:b0:19f:6fae:d5fc with SMTP id k1-20020a05687015c100b0019f6faed5fcmr5716930oad.33.1692564269036; Sun, 20 Aug 2023 13:44:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Sun, 20 Aug 2023 16:44:16 -0400
Message-ID: <>
To: Christian Huitema <>
Cc: Toerless Eckert <>,
Content-Type: multipart/alternative; boundary="00000000000003f97a060360d4a8"
Archived-At: <>
Subject: Re: [arch-d] Proposed IAB program on Wholistic Human-Oriented Discussions on Identity Systems (WHODIS)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Aug 2023 20:44:31 -0000

On Sun, Aug 20, 2023 at 4:27 PM Christian Huitema <>

> On 8/20/2023 12:39 PM, Phillip Hallam-Baker wrote:
> > On Sun, Aug 20, 2023 at 12:42 AM Toerless Eckert <
> > <>> 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.
> Many devices have an identifier that is very hard to change, for example
> MAC addresses, the VIN for cars or the IMEI of phones. Yet these devices
> have strong de facto linkage to the people who use them. If we want hard
> to trace identity for people, we have to make the device identity either
> very hard to access or very easy to change.

MAC addresses used to be hard to change until it became easy and then was
made hard again.

My first residential gateway had a fixed MAC, the next 6 made it trivial to
clone, then DOCSIS came along.

One of the things that came out of the IETF privacy worksop in the wake of
the PRSIM breach is that we managed to sufficiently convince the IEEE folk
that if they wouldn't do switching WiFi MAC addresses, maybe we would.

On cars, the big problem is actually the tire pressure monitors which are
wireless and use a fixed ID. It is pretty easy to make use of randomized
identifiers that can only be used by the relying party.

The way to fix this is with a shared key that is known to the car and the
pressure monitor. This can easily be provisioned by a QR code exchange with
the activation code being printed on the package the monitor comes in.

To send a message communicating its unique identifier ID and current status
Status, the device generates a random nonce n and sends the message  {
nonce, E (ID + Status, k) } where E is OCB encryption mode.

OK so this means that the car has to decrypt every message from every
device sending tire pressure readings. But that isn't much of a problem.
The overhead of OCB is probably very much less than the overhead of
decoding the radio messages.

Back in 1995, using encrypted IDs was wildly impractical, now it can be
routine. The auto industry needs to get a clue and standardize on a small
number of standard VLSI components anyway. The cost of standardizing on a
32bit part is probably negligible at this stage in the game. But even 16
bit parts can do the job unless hobbled by 1970s assumptions that 32
bytes of memory are enough