[Anima] Re: [Add] Re: Hosting Encrypted Servers on CPEs / HTTPS for Local Domains

Toerless Eckert <tte@cs.fau.de> Tue, 10 September 2024 15:51 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 44210C14F6B0; Tue, 10 Sep 2024 08:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 p5dYqRXiOCg2; Tue, 10 Sep 2024 08:51:16 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (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 1D50FC14F619; Tue, 10 Sep 2024 08:51:14 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4X37Tq1jqqz1R65l; Tue, 10 Sep 2024 17:51:11 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4X37Tq126ZzkxG4; Tue, 10 Sep 2024 17:51:11 +0200 (CEST)
Date: Tue, 10 Sep 2024 17:51:11 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <21866.1725908702@obiwan.sandelman.ca>
Message-ID-Hash: 5MFTIHAZWHAL2EKJQNNZECZJSCJIDIZZ
X-Message-ID-Hash: 5MFTIHAZWHAL2EKJQNNZECZJSCJIDIZZ
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
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/u03leUBBTyfFRT9fc-0vYaOvmC8>
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>

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:

- URLs need to have muggle safe, simple human recognizeable domain names
- The authenticity of the domain names is validated via a WebPKI certificate

But because of the dominance of this use case, it seems that all software and solutions
we're working on are viewed as necessarily having to fit into that problem field.

- TLS libraries only allow you to validate WebPKI certificates
- IETF Working groups (6MAN) reject drafts for e.g.: link-local,scoped IPv6 addresses
  in URLs because they are difficult (and unnecessary) to implement for browsers
  command line interface.

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).

Cheers
    Toerless

On Mon, Sep 09, 2024 at 03:05:02PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert <tte@cs.fau.de> wrote:
>     > If i want to go through all the trouble of A), assigning muggle friendly names first,
>     > then i really wonder if we're promoting the best solution by first looking into
>     > .local solutions instead of trying to figure out what's missing so that i can run
>     > my own ACME certification on e.g.: my home (or private industry/enterprise) network's
>     > router for my own global domain. And how to get this all auto-configured so that
>     > muggles can operate it. I for once am not aware of any easily deployable self-hosted
>     > ACME server solution, and if whatever we come up with for .local would not be a heck
>     > of a lot easier than ACME, then we're not going to get that deployed either in the
>     > networks where we would like it.
> 
> ACME is mostly about establishing authorization of the device across the
> Internet using DNS. (Either DNS-01, or indirectly DNS for HTTP-01 challenge).
> 
> I'm not sure what it brings in a home network using .local.
> Doing EST with an unauthenticated TLS connection, but using IPv6-LL addresses
> would seem to be as strong as an HTTP-01 challenge would be.
> 
>     > In other words: I'd love to see good solutions for B), and i'd challenge the priority
>     > of A) (for .local) over solutions that do make global domain names more
>     > easy to use in non-internet
>     > use-cases. After all, it could be piece of cake to add my own networks root-CA to
>     > my browsers web-pki trust-anchor list if we wanted that to be the solution.
> 
> It's a piece of cake for you, and your five devices. Harder when you have
> five members of the household with five devices each, and then guests.  And
> then, device to device communication.
> 
> Would you like to be able to shush your multi-room surround-sound music
> so that you can hear: the door bell, the coffee is ready, or the oven has
> preheated, waiting for the next tray of ordeuves?
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
tte@cs.fau.de