[Settle] Re: Referee proposal

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 09 July 2025 19:29 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: settle@mail2.ietf.org
Delivered-To: settle@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A05194213C70 for <settle@mail2.ietf.org>; Wed, 9 Jul 2025 12:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.017, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.232, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ11_-8aOQgU for <settle@mail2.ietf.org>; Wed, 9 Jul 2025 12:29:58 -0700 (PDT)
Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2F94C4213C69 for <settle@ietf.org>; Wed, 9 Jul 2025 12:29:58 -0700 (PDT)
Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6fafd3cc8f9so3828456d6.3 for <settle@ietf.org>; Wed, 09 Jul 2025 12:29:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752089397; x=1752694197; 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=HxPtiKb/cZzkONFpsbOPNg3eZuIlVbOcpx34+AHsbDU=; b=JOzj7peDoztgaEyqhRGS4ksps6my/DQ9OOpIbP9AMZM5dhqEfY7HFRVBiXpgDleDZJ +Ts7NnuJtX2xXWxj9COzaJSa4SYVIYNEUSawKe+hP3eO6phxbxrKtRZUJXXFKw3jXeuC qmXA+ABdL4EA4XXsN9Nvedmtw5Q6oPV5d1yA96+SwbhBcexEpcmLnPRFB917xYcJH7Xf hvlxe+xYN3DwJ4S8Q9RJydkg9q+ejfTjRyvsqs4t75GZpXs09/PtgP6mMH7TepPo8RHt 8nlmyKcIeEzvLT5UXu+KWF3RtHvpPaXNv6GsK3uspJlnUTaZREaVMzC6HvmCsw1PsQqk kwyg==
X-Forwarded-Encrypted: i=1; AJvYcCX0wUU4dRLnDqHVd/ZBHyW1+PJL686ygTtKesuDH16iIrLpeix8nTSwsA5siG5mDpg3H+iHIFU=@ietf.org
X-Gm-Message-State: AOJu0YyxkkEk0jab7bij4aiqMjMses80I9k6zSWTNo5jE+lJIT8zx+iF 6UeOBs319RhbAM7izKf5tR9odSsZQfLvoJFIXf/aSvtunjz9kcJlm5hTSGUt2vw9lrUHCToza2f xARv6jC+3EXWLLPwwVZaFNqNDw8mjBPo=
X-Gm-Gg: ASbGncuBq+jl0QXyXqCVbbJFjqnSH9KBcvlpmYmBrHT34AQaKwjTYhG2gOzqEHlzuMm I3MZ3QhCYyNy/XnJ/I6Saaupo26DYO1JW+Mbc+Rwe20KRcrf90fKy29tZmBgoHtpNk/RTIP9zeU hvgaLSqImqnWCo1FIfGh6R8SP2gkTzPPPdHGKvg9nJApMnqMijIbsKnqNehmsqnLimdubMb6PBd bYzqQ==
X-Google-Smtp-Source: AGHT+IEW5SbPy/jYnFgQ/gixjlQt0gaV2wdBvYLGlTOOl+S9rbG/G0GZGo1fEfF6LWa0SGR8Nf5tw2X7xsCjrfEAKUc=
X-Received: by 2002:a05:6214:5190:b0:6fa:c054:1628 with SMTP id 6a1803df08f44-70494f8042cmr21434526d6.23.1752089397484; Wed, 09 Jul 2025 12:29:57 -0700 (PDT)
MIME-Version: 1.0
References: <21331.1751827141@obiwan.sandelman.ca> <CABcZeBMHO78mxMXZ2zaA2WtZmwFiH+-FzjYGB3Rg3gSTeL++Sw@mail.gmail.com>
In-Reply-To: <CABcZeBMHO78mxMXZ2zaA2WtZmwFiH+-FzjYGB3Rg3gSTeL++Sw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 09 Jul 2025 15:29:45 -0400
X-Gm-Features: Ac12FXzg-DBVFuojEYW52FqlnYrK5G8hTYDAohtzFs1sAd6VJ4r51iFkRhzNyEM
Message-ID: <CAMm+Lwj6ZwnJDx=Kt6-Z17VimPN8j4-mB4tFrfa1w2APhob=3w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="00000000000026e3d80639841a19"
Message-ID-Hash: HZKURQQKOCHRFCDBPD2YUWYSR6GP4VX5
X-Message-ID-Hash: HZKURQQKOCHRFCDBPD2YUWYSR6GP4VX5
X-MailFrom: hallam@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Michael Richardson <mcr+ietf@sandelman.ca>, settle@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Settle] Re: Referee proposal
List-Id: "SEcure access To Tls Local rEsources. To discuss non-PKI methods of identifying and authenticating to TLS endpoints in a local domain." <settle.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/settle/OWSN9QJQeNPbdXazlPfIMStZ5Bk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/settle>
List-Help: <mailto:settle-request@ietf.org?subject=help>
List-Owner: <mailto:settle-owner@ietf.org>
List-Post: <mailto:settle@ietf.org>
List-Subscribe: <mailto:settle-join@ietf.org>
List-Unsubscribe: <mailto:settle-leave@ietf.org>

On Sun, Jul 6, 2025 at 3:09 PM Eric Rescorla <ekr@rtfm.com> wrote:

> I've reviewed this draft and I'm less sanguine about it.
>
> First, the discovery of the referee is a reduction to a previously
> unsolved problem, which is whether you ought to trust some random
> device on the network that responds to a network request. Section 7
> says that this decision is "out of scope of this document" but this is
> the central problem.
>

Agreed. But I see this as driving a constraint. The user needs to make some
form of 'affirmative interaction' to authorize the device onto their
network. For example:

* User scans a QR code on the device.
* User interacts with the device via Bluetooth or NFC.
* Purchaser is given code by vendor that is passed to the network
management system to authorize it.
* Unauthenticated devices are automatically segregated on a 'quarantine'
network until they are authorized.

This is the authorization side of the authentication problem. There is not
going to be one approach meets every use case but we can cover most of them
with a combination.