Re: Link-local connectivity in Web browsers
Toerless Eckert <tte@cs.fau.de> Tue, 27 February 2024 17:11 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A347C151081 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 09:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.757
X-Spam-Level:
X-Spam-Status: No, score=-7.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=w3.org header.b="j9bfXjpZ"; dkim=pass (2048-bit key) header.d=w3.org header.b="eljuzyvo"
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 SjOb2bOUVhIC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 09:11:02 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACF0C14EB17 for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 27 Feb 2024 09:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Cc:To:From:Date:Reply-To; bh=G05mJbEzWK9UqOaFHHGH1ToTyGaWoNdoNEHF2gXoihE=; b= j9bfXjpZd2CEXk3w4ucPYfK4B922aaVkc2ZX1myT1yxdmyyHGn/31Tp82Y0oigxmB2HL3Pxb9CpUd Q4xiX69CyJR9DwNSQ/tP66yAjlloyao0LgKVMb67UyRll5ZicQUG17uXlvETxH8dNU1exO2H0xwnc Pfqy0miUKEiWpFWfiAO17g03Mi78Iq6KyrIU7n9UMHgsQ7QL7PpapVzz88CTvMIXb+x2Tk74Px72X pcTksp632UBfmH6nK8Kpm5mSAbxrj/FIo4j9Aes1JG95bfnfD2+wHBDUzhQQBjtA9OzHKQ2u412cV MOVUkR6PFWmKXlw49Tc43LH/QptkdVGZqg==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rf0yV-002yHv-HG for ietf-http-wg-dist@listhub.w3.org; Tue, 27 Feb 2024 17:10:39 +0000
Resent-Date: Tue, 27 Feb 2024 17:10:39 +0000
Resent-Message-Id: <E1rf0yV-002yHv-HG@lyra.w3.org>
Received: from pan.w3.org ([3.222.182.102]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <eckert@i4.informatik.uni-erlangen.de>) id 1rf0yT-002yGt-5n for ietf-http-wg@listhub.w3.org; Tue, 27 Feb 2024 17:10:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Reply-To; bh=G05mJbEzWK9UqOaFHHGH1ToTyGaWoNdoNEHF2gXoihE=; t=1709053837; x=1709917837; b=eljuzyvo2SR7WHlW6Ss+Vy4iX73qoGK9w1g3FRlcFKTcsOW 72KiL9ywBhBoyjfH+Mum1AsEQtAaAz27+hKI3rXxep0bm4knLtWrVedc/rd6eRYBgtJcXivirCJoe 3N62LGvwvwJ6mRcU7xqbYGqVpFoAxdIPnqgpasYFvSoz8Ol8qp6n/RxMajOeLJf/RbqpW8TSzpyeM SsFhDSP+8uFHcJFisK1mfLOK5Qu04OzdWVx0XHtl13n5KGm5M05lKzPkm7kjIvgYPjDbdzpTAkTQj 4GCM3eRythLCDVsKjaCQwvAapHpTg2qd68e4KmhgZAe2zNTadZqJQSy2prolRKMQ==;
Received-SPF: pass (pan.w3.org: domain of i4.informatik.uni-erlangen.de designates 131.188.34.40 as permitted sender) client-ip=131.188.34.40; envelope-from=eckert@i4.informatik.uni-erlangen.de; helo=faui40.informatik.uni-erlangen.de;
Received: from faui40.informatik.uni-erlangen.de ([131.188.34.40]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <eckert@i4.informatik.uni-erlangen.de>) id 1rf0yR-004wAx-1N for ietf-http-wg@w3.org; Tue, 27 Feb 2024 17:10:36 +0000
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 4TkkWm53b6znkTh; Tue, 27 Feb 2024 18:10:28 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4TkkWm4FlVzkmxj; Tue, 27 Feb 2024 18:10:28 +0100 (CET)
Date: Tue, 27 Feb 2024 18:10:28 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Ben Schwartz <bemasc@meta.com>, Michael Sweet <msweet@msweet.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Zd4XhCw0FB0v3RSu@faui48e.informatik.uni-erlangen.de>
References: <Zdamt16camKdi-z8@faui48e.informatik.uni-erlangen.de> <22C7EB50-FA1F-4DD5-9A92-ACAF54DD5B3C@msweet.org> <ZdfHM64RdHLHXQ4H@faui48e.informatik.uni-erlangen.de> <SA1PR15MB4370D9A3CB02716FB228D59EB35A2@SA1PR15MB4370.namprd15.prod.outlook.com> <Zd01iJLSs4qWnjEj@faui48e.informatik.uni-erlangen.de> <CAPDSy+5qHB0ih19aC=R5gM2j1z01x9goa=EXV=kYOj-1TaGE9g@mail.gmail.com> <Zd1IlafNogGHtaWK@faui48e.informatik.uni-erlangen.de> <CAPDSy+6B+07vm_cZbhDvWo=AOkyP-jMLC-Jx9bbEEVv4yBV5sA@mail.gmail.com> <Zd1RKPqsHcH9i_Yo@faui48e.informatik.uni-erlangen.de> <CAPDSy+61FKTrmRef2mHZiYBL_-fFPaaAmYuRcN+ao-HSMLSErw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPDSy+61FKTrmRef2mHZiYBL_-fFPaaAmYuRcN+ao-HSMLSErw@mail.gmail.com>
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1rf0yR-004wAx-1N c20472a3e6fe9bc6be5ff6c6a6e902c9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Link-local connectivity in Web browsers
Archived-At: <https://www.w3.org/mid/Zd4XhCw0FB0v3RSu@faui48e.informatik.uni-erlangen.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51845
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On Mon, Feb 26, 2024 at 09:19:48PM -0800, David Schinazi wrote: > > Correct me if i am wrong, but is it not true, that this discussion took > > only place in the context of browsers, but not the broader set of software > > that is using HTTP(S) even programmatically such as in REST APIs ? > > No, that discussion happened in the context of HTTP and URIs. It was not > specific to browsers. You can search for curl and wget in these threads to > get examples of non-browser software. For example: > https://mailarchive.ietf.org/arch/msg/ipv6/lLWV1WVmUxqN42fYQ-dlnI2d70U/ But i can not remember having seen any implementations/use being mentioned where at least the client is not a browser but some other application using URLs, for example programmatically. Neither was this considered i think in Murray's DISCUSS. > Is it not also true, that we have with browser a particularily difficult > > industry because it has convered to very few browser cores, namely > > chrome and firefox, which are re-used by a much larger number of > > significantly > > used browser in the industry, so effectively only two implementers have a > > real > > say when it comes down to implementation ? > > I'm sure the folks over at Apple would have opinions about that statement, > but yes there is a small number of browsers today. That is a reality. Maybe "browser-cores" or "platforms" - i am sure ther must be a fitting term. I don't want to diminish the work all the differnt browser do on top of those shared cores. It's a good model unless it comes to ugly issues like what we run into here. > In addition: I have heard from one implementation attempt, and i can > > agree that these two browser cores are very complex. However, i am > > not persuaded, that this necessarily equals complexity in the standards > > process modelling that you claim to exist. After all, i think that > > was some good amount of examples here on the thread that the existing > > origin model does already carry security issues with it, that are simply > > being ignored because they are seemingly not significantly exploited. > > > > Aka: Given how the IETF has all of networking based on IPv6 at the > > network layer, and we can not change that to eliminate link-local > > addresses, and we also can not expect all use-cases to use (m)DNS > > (which also has other issues as we discussed), i think it is quite > > important to at least outline the standardization/security implications > > first and independent of the likely implementation effort so that > > we can judge them. > > > > I think thinking through such security implications and writing them down > is always a good idea. I look forward to reading your draft! I'm also > curious to hear about these use-cases that cannot be solved by mDNS. Well, the security issues would be where we need the HTTPS community input, i wouldn't know. And yes, the use-cases is where we folks from the "crappy network setup side" need to collect more info. But remember that my core thinking in this discussion is that scoped link-local addresses are a core underutilized part of the IPv6 architecture, and whenever we have put our mind to it, they did help us to improve/simplify solutions over IPv4. But to be able to do that in the context of HTTPS based user-machine or machine-machine communication, we first need to come to a solution how we can use them in URLs. Only then i think will we have enough of an architecture that application solutions using e.g.: REST APIs could start thinking how to benefit for link-local addresses. In other word:I reject the notion that we need to show overwhelming business need on browsers to justify that scoped IPv6 addresses in URLs need to be standardized. I do agree though that browsers only need to implement such a standing if and when they have sufficient business case. And i think we need to do our best to ensure we do put into the standard the best technical solution - as we understand it. > We have a lot of smaller areas in the industry, where smaller use-cases > > have resulted in custom setups of browsers, so i do not even agree > > to the assesment you and Murray do that WHATWG is the only relevant > > candidate implementers circle. > > I don't understand what you mean. I only mention WHATWG in that they own > the URL spec used by browsers. > > But at this point I think we've reached the limits of email back-and-forth, > and might benefit from verbal communication, I'll ask for some agenda time > to present this draft in Brisbane and we can pick this up there. Agreed. Cheers Toerless > > David > > Cheers > > Toerless > > > > > David > > > > > > > > > On Mon, Feb 26, 2024 at 6:27 PM Toerless Eckert <tte@cs.fau.de> wrote: > > > > > > > Thanks, David. > > > > > > > > Neverthless i do not see a technical issue to extend what rfc9110 says > > > > about transmitting origin by e.g. not including local context (such as > > > > zone_id). > > > > > > > > The examples i think show that if we want to support the whole > > IPv4/IPv6 > > > > addressing architecture as well as also ambiguous domain names, that > > > > origin is not necessarily 1:1 between client and server except for > > > > the simple case > > > > > > > > - the client may need to distinguish zone_id > > > > - the server may need to distinguish client-source-ip-address (source > > > > country). > > > > > > > > And the problems aren't related only to IPv6 link-local. > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Mon, Feb 26, 2024 at 05:14:12PM -0800, David Schinazi wrote: > > > > > Hi Toerless, > > > > > The IP address is sent in the Host header. > > > > > David > > > > > > > > > > On Mon, Feb 26, 2024 at 5:06 PM Toerless Eckert <tte@cs.fau.de> > > wrote: > > > > > > > > > > > On Mon, Feb 26, 2024 at 03:10:35PM +0000, Ben Schwartz wrote: > > > > > > > I think it would help if this draft discussed scoping of cookies > > (and > > > > > > other HTTP client state). In particular, I shouldn't be able to > > > > vacuum up > > > > > > your home "printer-123.local"'s cookies just by naming myself > > > > > > "printer-123.local" on the coffee-shop network. Client state for > > > > .local > > > > > > domains needs to be partitioned by network to avoid these attacks. > > > > > > > > > > > > Not sure how to actually trigger the attack unless the user > > actively > > > > > > connects to > > > > > > that attacker in the coffee-shop explicitly, but architecturally > > you > > > > are > > > > > > of course > > > > > > putting the finger on the problem. > > > > > > > > > > > > Not sure if this problem has an existing technial term, but i would > > > > call > > > > > > it "ambiguous name/addresses". > > > > > > > > > > > > My last experience with this was when i set up a second Internet > > > > > > connection at home for > > > > > > reliability and other reasons, both Internet connections then had > > the > > > > same > > > > > > vendors type of > > > > > > router (Germany, AVM "Fritzbox"), both using the same IP address > > > > > > 192.168.178.1 and mDNS > > > > > > name fritz.box (*). > > > > > > > > > > > > So, oviously, when i connect my notebook from the SSID for one > > internet > > > > > > connection to the > > > > > > SSID of the other internet connection i do get all type of crappy > > > > > > web-browser results, because > > > > > > there are all type of incompatible cached web pages from the prior > > > > SSID's > > > > > > routers web interface. > > > > > > > > > > > > The same of course is happening, when i am streaming content from > > some > > > > > > web-page, > > > > > > and then i am changing my network path to come in via another > > country, > > > > > > because those domain name > > > > > > are actually offering differnt services depending how i arrive at > > them, > > > > > > and hence cached > > > > > > web-page information is really incorrect after such a change. > > Again, it > > > > > > does not depend > > > > > > on whether i am using an anycast address or a domain name, i am > > just > > > > > > running into use-cases > > > > > > that show the fact that even supposedly global names/addresses are > > not > > > > > > really global, but > > > > > > will also depend on the routing path. > > > > > > > > > > > > So, if i was to generalize this problem, i end up with: > > > > > > > > > > > > https://<dnsname>%<network-context>/.. > > > > > > https://<ipaddress>%<network-context>/.. > > > > > > > > > > > > Aka: IMHO i can pefecty well disambiguate these cases by adding > > > > > > network-context to the origin > > > > > > which is only evaluated by te local host. David Schinazi is > > pointing > > > > out > > > > > > that RFC9110 says that > > > > > > all part of the origin need to be sent to the remote system, and > > that > > > > may > > > > > > be a problem for > > > > > > ambiguous DNS names, but AFAIK it would not be a problem for > > > > IP-addresses, > > > > > > becasue they > > > > > > are not sent in server_name in TLS nor AFAIK in the Host: header. > > So > > > > even > > > > > > without a %zone_id, > > > > > > i think the RFC9110 statement is correct - i may be wrong. > > > > > > > > > > > > In any case, that's what i was trying to get bck from David, but > > have > > > > not > > > > > > seen a reply to my > > > > > > repeated asks to him about it. > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > (*) I think AVM came up with their .box pseudo TLS before they > > > > understood > > > > > > .local, and some time > > > > > > ago there was a reall .box TLD allocation happening, so now they > > have > > > > > > another fun problem to > > > > > > solve with their pseudo TLD. Talk about ambiguous domain names... > > > > > > > > > > > > > > > > > > > > I also think opportunistic encryption (RFC 8164) should be > > considered > > > > > > seriously in this context. The security properties of local > > networks > > > > are > > > > > > different from the public internet, and opportunistic encryption > > seems > > > > to > > > > > > provide more value in this context. > > > > > > > > > > > > > > --Ben Schwartz > > > > > > > ________________________________ > > > > > > > From: Toerless Eckert <tte@cs.fau.de> > > > > > > > Sent: Thursday, February 22, 2024 5:14 PM > > > > > > > To: Michael Sweet <msweet@msweet.org> > > > > > > > Cc: David Schinazi <dschinazi.ietf@gmail.com>; HTTP Working > > Group < > > > > > > ietf-http-wg@w3.org> > > > > > > > Subject: Re: Link-local connectivity in Web browsers > > > > > > > > > > > > > > On Thu, Feb 22, 2024 at 07:04:33AM -0500, Michael Sweet wrote: > > > > > > > > >> 2. Locally-Unique Addresses (ULAs) can be assigned > > automatically > > > > > > and are better supported by the various client OS's than the RFC > > 4007 > > > > > > default scope for link-local addresses. > > > > > > > > > > > > > > > > > > I am not aware of schemes that would automatically assign > > ULAs, > > > > > > would love a reference. > > > > > > > > > I have written a scheme based on network wide > > > > > > configuration/autoprovisioning (RFC8994), but > > > > > > > > > i am not aware of any similar solutions like that widely > > used. > > > > > > > > > > > > > > > > Enterprise networks often make use of ULAs, and that is where I > > > > would > > > > > > expect them to be used most often since 'normal users' don't > > typically > > > > have > > > > > > the expertise to set those things up. > > > > > > > > > > > > > > Sure, but there is no "assigned automatically" the way i > > understand > > > > it. > > > > > > YOu may have > > > > > > > meant something different, so maybe its not a sufficiently well > > > > defined > > > > > > term. > > > > > > > > > > > > > > But in any case, ULA like global addresses do require additional > > > > address > > > > > > allocation/management > > > > > > > operations which may not have happened and/or which may not be > > > > desirable > > > > > > to be required, > > > > > > > so the underlying interest at least IMHO from the IPv6 networking > > > > world > > > > > > is to figure out > > > > > > > what the sanest way is to support LLA across all representations > > > > where > > > > > > they may be needed > > > > > > > including browsers. That's nonwithstanding that we wuold want to > > > > > > minimize the need > > > > > > > for having to use any IPv6 address by normal users under normal > > > > > > circumstances. > > > > > > > > > > > > > > Cheers > > > > > > > toerless > > > > > > > > > > > > > > > ________________________ > > > > > > > > Michael Sweet > > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > -- > > --- > > tte@cs.fau.de > > -- --- tte@cs.fau.de
- Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Michael Sweet
- Re: Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Michael Sweet
- Origin concept Q (was: Re: Link-local connectivit… Toerless Eckert
- Re: Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: Link-local connectivity in Web browsers Michael Sweet
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: Link-local connectivity in Web browsers David Farmer
- Re: Origin concept Q (was: Re: Link-local connect… David Schinazi
- Re: Link-local connectivity in Web browsers Ben Schwartz
- Re: Origin concept Q (was: Re: Link-local connect… Toerless Eckert
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: Link-local connectivity in Web browsers David Schinazi
- Re: Link-local connectivity in Web browsers Toerless Eckert
- Re: David/*: Origin concept Q (was: Re: Link-loca… Toerless Eckert