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 01:01 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 66C13C15109A for <architecture-discuss@ietfa.amsl.com>; Sat, 19 Aug 2023 18:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.406
X-Spam-Level:
X-Spam-Status: No, score=-1.406 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_NONE=-0.0001, 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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7CUMxSlcWY8 for <architecture-discuss@ietfa.amsl.com>; Sat, 19 Aug 2023 18:00:55 -0700 (PDT)
Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (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 DC423C15108F for <architecture-discuss@ietf.org>; Sat, 19 Aug 2023 18:00:55 -0700 (PDT)
Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-1c4d67f493bso1556270fac.2 for <architecture-discuss@ietf.org>; Sat, 19 Aug 2023 18:00:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692493255; x=1693098055; 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=KazhnWttuDd3OKm2IYwMIhOQ88CpCLJiaIyAIWvr4yE=; b=iPeaN2CFyXjBkzEfRpYdle92/6dS5HrgJ/r1NECC+xE4+C2V9bgIyQ8Mig1fK7Tk5k MZl7ajNIbWHADqkYC7PLGYbp/nnDnfJbnTLJNvFau+A6iurF0KHOlVuMAcDOiidtmfLH jlBMfU61G02aL+3h5cYR9bnnlf8RpBusF9gv6sJRm39Pm9saZbUq1cZ8hV2dP+EDv0lz EvIa9rMLg4irrYD6TZcVN4fzc6uoFTEhAWy2Lp6SNUX9CFdHGiyUMCSLX36AALwkLnuc XQZIScrMi7iuslDqr8tOghDEZ7CIwshfHM4i4CkYLIsfE3d4hHZX3psqfGI+mL7JYlgX 7PjQ==
X-Gm-Message-State: AOJu0YzBpizdVdZAOqwoQ+dJcvWr1lTDu/gjZdL5+O+nhyH8a+MOta0q /Is53LQOXmWmR9NRAf5vAdwaF1iIvJ8ccxulBuU=
X-Google-Smtp-Source: AGHT+IEC7zN7fhLgGAlJJnMsbv8Ti99zsNzockeZpGRQn4ZmWo/NzfhY7+vcot50t/61idU+Y64Vi23aRbg20pgls6I=
X-Received: by 2002:a05:6870:d620:b0:1b3:738e:a341 with SMTP id a32-20020a056870d62000b001b3738ea341mr4296565oaq.46.1692493254993; Sat, 19 Aug 2023 18:00:54 -0700 (PDT)
MIME-Version: 1.0
References: <17514E09-F39D-425C-970C-BC14C70F15B9@heapingbits.net> <d65583b8-7706-ddbd-1430-ba353e05bfee@lear.ch> <0439cbdf-fe23-4ffd-8b43-3d1494d7eb73@betaapp.fastmail.com> <47a9db87-9e08-4c7c-c213-68ee36aa0385@lear.ch> <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>
In-Reply-To: <ac2dd449-3a67-6aef-279f-62426be9c1a9@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 19 Aug 2023 21:00:42 -0400
Message-ID: <CAMm+Lwjy34hofa+R4_KgVRZBv5y14c2R=HJ6kQNDsA0ZmrmWkg@mail.gmail.com>
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003fac9b0603504bd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ynSZmfqHE4r-J2aE0UpnlmAQ42c>
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 01:01:00 -0000

On Sat, Aug 19, 2023 at 8:22 PM Hesham ElBakoury <helbakoury@gmail.com>
wrote:

> Is there a decision regarding whether device identity should be included
> in the program or not for device-to-device and device-to-network?
>
> Thanks
>
That is a good question at many levels.

First off, we did have a working solution for establishing corporate
identity on the Web for almost 20 years. Some of that work is still
relevant to attempting to credential or identify people. And understanding
why attempts to extend the WebPKI model to people failed is also relevant.

Secondly, I think we need to take device identity separate from service and
user identity. These should be considered separate concerns.


Let's consider the case where Alice is going to use a site hosted on
MegaSite which has 2000 domains on the same IPv4 address. We would like to
encrypt the initial contact so Eve doesn't know which one. There are two
ways we can do this. One is to delay notice of the service we want to
connect to until after we have received a public key, i.e. the second IP
packet. The other is to stuff a public key into the DNS.

In either case, that public key is really a host public key, not a service
public key.


When looking at the next generation of security solutions, I believe we are
going to be focused on separation of roles, one technique for that is
threshold of course but it isn't the only one. Cryptographic hygiene, using
separate keys for separate applications, being able to track back
administration actions to specific individuals and specific devices becomes
critical.

For example, Alice has her car broken into and her laptop stolen. The
attacker may have been able to bypass the authentication on the device and
SSH into the machines Alice administers. But did they? Only way to be sure
is if we have logs that show which actual device connected and that means
Alice using a different SSH key for each device.