[Anima] Re: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local Domains
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 10 September 2024 18:03 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E530C18DB89; Tue, 10 Sep 2024 11:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 4pBEYYq4exX9; Tue, 10 Sep 2024 11:03:18 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA5BC1840F2; Tue, 10 Sep 2024 11:03:17 -0700 (PDT)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.a=rsa-sha256 header.s=dyas header.b=ZWtZ4RhL; dkim-atps=neutral
Received: from dyas.sandelman.ca (unknown [24.48.10.190]) by relay.sandelman.ca (Postfix) with ESMTPS id E5D721F483; Tue, 10 Sep 2024 18:00:23 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 64D23AB65C; Tue, 10 Sep 2024 14:02:59 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1725991379; bh=xpzinn3928ywOTqOygP9DOQqKvLaYbNL2xgBUw+A0JM=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=ZWtZ4RhL+43jjkz6Rpqr6H9RD+ylGVpCvazq+T27BdsgTBi2tKi3hxKVNCOL4aeQ8 vItch51AqjPBiLzI56/Kho3jIiWEcQnXllWVnEDUWx8yD8ToH6oqv04BtnqkqPyMPO 1qtSI0GI6xN3F4Tfl7ryrVDaF3pXwQZwC/mn3Y15bgAav0h4wVXbdHaA7zreQNCUXq qldzl3O5fjvj9nX7zfTlraUc+K29g8L8ErxG0B5MGSflN1GHX0P6VHorJ6ZpeMZOE+ qDa4twKRzT2d3zhRxhc8ywHA/MU6gLygbbuvZAytRNw+XNn9fFULM/dgw4Zkrcn5xs TkWCHr+bgg3ww==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 625D1A1466; Tue, 10 Sep 2024 14:02:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>
In-reply-to: <ZuBq7_G6tcggpUbO@faui48e.informatik.uni-erlangen.de>
References: <6FCA933A-F329-4B45-9C72-32FFCAD289BE@gmail.com> <CACJ6M16MgxzE+8Yiebd9hbYC_tY2tt0Sroc4_izOnP3kO3e5fQ@mail.gmail.com> <MW4PR15MB437956E8735320FFE83037C7B3952@MW4PR15MB4379.namprd15.prod.outlook.com> <ZtpGfh15m58gId0Z@faui48e.informatik.uni-erlangen.de> <21866.1725908702@obiwan.sandelman.ca> <ZuBq7_G6tcggpUbO@faui48e.informatik.uni-erlangen.de>
Comments: In-reply-to Toerless Eckert <tte@cs.fau.de> message dated "Tue, 10 Sep 2024 17:51:11 +0200."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 10 Sep 2024 14:02:59 -0400
Message-ID: <376984.1725991379@dyas>
Message-ID-Hash: EQCJWAAAF6DXMDXJVYS6BQ2ILIKWXX3Q
X-Message-ID-Hash: EQCJWAAAF6DXMDXJVYS6BQ2ILIKWXX3Q
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "add@ietf.org" <add@ietf.org>, anima@ietf.org, iotops@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local Domains
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/omFjMHmR3pMCBJgIFKLXTp_FhB0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>
Toerless Eckert <tte@cs.fau.de> wrote: > My main point was that we seem to be trying to build workarounds for a > problem that exists (IMHO ONLY) for targets/URLs that may need to be > entered by muggles into browsers. For this case, W3C has come up with a > nice useful approach: I am not convinced that's the exclusive case. That's the case *today*, because we don't have interoperable IoT APIs. WoT, SENML, NIPC/SDF, OPC UA, Matter. All these things will bring useful APIs, and then people will want to do more, at which point device A needs to validate device B. Yes, for HTTPS, but possibly also for CoAPS, QUIC ... > - URLs need to have muggle safe, simple human recognizeable domain > names - The authenticity of the domain names is validated via a WebPKI > certificate I don't think it's the W3C that says this, I think it's RFC9525. > - TLS libraries only allow you to validate WebPKI certificates That's not really the case. They make it **easy** to validate the pre-loaded system certificates, which in most cases it the same thing. Applications *can* add new anchors either implicitely (adding to the system certificates), or explicitely ("--cacert" to curl, for instance). > IMHO, i would really lvoe to see TLS not being constrained to only > browser business, but i'd love to use certificate authentication where > feasible for all IOT environments. But that won't work with WebPKI > certificates. And that's highly annoying because we already know how it > is easily feasible to build IOT specific certificate extensions > (because we've done it for other use cases in other RFCs). Agreed. To add some ADD content back [pun intended]: ultimately, home CPEs would just be mains-powered IoT devices with really good connectivity. If IoT had already solved the problem, then ADD wouldn't have to. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Toerless Eckert
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Erik Nygren
- [Anima] Re: [Add] Hosting Encrypted Servers on CP… Dan Wing
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Toerless Eckert
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Toerless Eckert
- [Anima] Re: [Add] Hosting Encrypted Servers on CP… Michael Sweet
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Toerless Eckert
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Michael Richardson
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Michael Richardson
- [Anima] Re: [Add] Hosting Encrypted Servers on CP… Dan Wing
- [Anima] Re: [Add] Re: Hosting Encrypted Servers o… Michael Richardson
- [Anima] Re: [Add] Hosting Encrypted Servers on CP… Brian E Carpenter
- [Anima] Re: [Iotops] [Add] Hosting Encrypted Serv… Michael Sweet
- [Anima] Re: [Iotops] Re: [Add] Hosting Encrypted … Michael Sweet