Re: Link-local connectivity in Web browsers

David Schinazi <dschinazi.ietf@gmail.com> Tue, 27 February 2024 01:14 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 86005C1C6340 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 26 Feb 2024 17:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.856
X-Spam-Level:
X-Spam-Status: No, score=-7.856 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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="A1BwDUeQ"; dkim=pass (2048-bit key) header.d=w3.org header.b="oCqu68Iy"; dkim=pass (2048-bit key) header.d=gmail.com header.b="VFSnQ0/Q"
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 AKkFXvtNtuH9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 26 Feb 2024 17:14:49 -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 8B4E7C19ECBF for <httpbisa-archive-bis2Juki@ietf.org>; Mon, 26 Feb 2024 17:14:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=G2MjrD77Mvyo6APS1doU/EM72Ps3szq5shmU4lzjI94=; b=A1BwDUeQ1nwO2pRHKA9gTVAlfU WN2kw10BRQJ+ISR0AhwP8wEIlHdF3QKp7UVjLbwGvOugOqgkR2AASf1P+TCTLoB8tjWyhK2PqmtsP fVnrScwffrska6sM7aRE3MIefdiYZqHQgE3aHnIjCgis9NYjkg1M+5H8uL8o4MGefMWIGN9RDvfcM JvW2Ey6f7jNPzYxPEBC8HJEW3VXC9T3bHqTSC8Bwl6f7XXStN0yjYhAbBeP2vl3BQ+855HWmFewQc hGyChUSktVBRTzWpjYaMDzx5fKPWkVG150o21tXvCki3X2b8ZSwEZDFKdwamnp+czUEzCiTrdnCUL O7RZ9j6A==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rem3I-000sDe-5i for ietf-http-wg-dist@listhub.w3.org; Tue, 27 Feb 2024 01:14:36 +0000
Resent-Date: Tue, 27 Feb 2024 01:14:36 +0000
Resent-Message-Id: <E1rem3I-000sDe-5i@lyra.w3.org>
Received: from puck.w3.org ([34.196.82.207]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <dschinazi.ietf@gmail.com>) id 1rem3C-000sC5-71 for ietf-http-wg@listhub.w3.org; Tue, 27 Feb 2024 01:14:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=G2MjrD77Mvyo6APS1doU/EM72Ps3szq5shmU4lzjI94=; t=1708996470; x=1709860470; b=oCqu68IyEAOzNaGduEoeKCVgZJgnmKrqGI2YIL3I2s2aFo/3cWPUFKC4MNGYBzpqKjLm5m9ZQ/z PARaD5jKe4coew8KurL/rUY27toVIiyEkBpDPfYS/TC9ncmTSo8vMGHDzl0gCLwsuYI6WDUmPtqV7 SnyUXVGjd9kEd2kmAeQp+sjSZeDLzabzF5UQdoDkoqjFyvh5u38mtV131+qk59t57rUxWklZFdBEW 760vfKbfGzLcqKDbOaXfbxnv3NxLI2cW1yGhykQmV+NFICQMcuwrgSH0BR6WLkNXkBLz0jS4T/7we OAn0PVjvPGCRit2bnqupW8OS1ybfZsEIdr1g==;
Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2a00:1450:4864:20::62c as permitted sender) client-ip=2a00:1450:4864:20::62c; envelope-from=dschinazi.ietf@gmail.com; helo=mail-ej1-x62c.google.com;
Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dschinazi.ietf@gmail.com>) id 1rem3A-002HD1-2c for ietf-http-wg@w3.org; Tue, 27 Feb 2024 01:14:29 +0000
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a3f4464c48dso435065966b.3 for <ietf-http-wg@w3.org>; Mon, 26 Feb 2024 17:14:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708996465; x=1709601265; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G2MjrD77Mvyo6APS1doU/EM72Ps3szq5shmU4lzjI94=; b=VFSnQ0/Qtzl7fFZIfHQCsftOoNU9M7QgiVxtLlWRa9ArRZjFfi8K3yAGPWEj5tBpG1 73IAVKnT+VdBek0byIum2hJOY6jI66Ot+Yh+uTNqrdBQ1Vu7TJsfkzkWGUvRw/Fx+iQ+ FhapQt0fsmkRD+0zLpPxcD2ne7oGTr3LGxGHXutpQoYPWMPCn9gFMScn6plpYZ4nq0K5 mEk55oh/rBuZljdpnCHDmrgOKsFUETA4Wk89JE0aM3zUXLiBnSnFjpg/cnffB1x4PF6j VnwyiQU0cDDp1B0sG1xkt2pSO7YCy1ojs5CYq0ORsy0qNcQzqknfUgoMv+dLqBWXHK/f 19BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708996465; x=1709601265; 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=G2MjrD77Mvyo6APS1doU/EM72Ps3szq5shmU4lzjI94=; b=VePiAaIg997gy5UeK8KXMzRlnmDJuuCMXQYbARNrasQxZApggemK8S/GmX0r1jlv9T AUYwh1DN23KrAGy9amFvmfWC2l5+HXoWJmdHBmiirF2IsIdj/SnMI0hUqQtj83A9look gSi85pjh8Xn7MAwFBeALa3a2ADq66+UJhHUEHQb1SI3WkMTKQJoPVwubTvxpUPJYbxMC 1LjECwf5yUNmeYeJJtZvWJwMvstf2/RFlAoRFBafFcEQlUjqtnrVQJWHsHrfVfTlrkYK R2TbNUOQzWNkLt05gGSOXnjeIEBOIxrJiWSnhJ92hT5wdbOQcrNWdi3FDK9JQ1EmHfFV fvaQ==
X-Forwarded-Encrypted: i=1; AJvYcCW0Iv2mUbbhLWwb3yboWlbjBK8WFEh+ubU5SkexphQrAgZalFCS1t5CY9fUfWT+9kn3MA58IOCiBdJFhg+JMluliRUa
X-Gm-Message-State: AOJu0YwHm1Vr9TDxskVT2CtNjI0j5R1jH/Fwq5QxdaB6b4oPsYhDzhDc 8zPoQikXG4/U+l+7J94D+Ym20JMybLIoaQc0+K6v7eLnd10op/RJMT1qOlwYsKspn7ck0pH5MMv u2Z2Z+wBR/rEawIH1MpVeCngKQpU=
X-Google-Smtp-Source: AGHT+IFB4wsYZnjETRgulJS6SZhOwsy2XG/s+pRtfYs9+20Xccv/3kJ5wLJtRMVS6pfxP3m9bVDIf/CyudTkFmVvxvQ=
X-Received: by 2002:a17:906:a256:b0:a43:199b:cc9c with SMTP id bi22-20020a170906a25600b00a43199bcc9cmr4156387ejb.75.1708996464615; Mon, 26 Feb 2024 17:14:24 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+7h3SSeKyA2CUazyWWsUi6+xhn2i91zNW1uz4NhgOGkug@mail.gmail.com> <AA46BAE0-EEC9-4985-AEFC-DF2423C9E582@msweet.org> <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>
In-Reply-To: <Zd01iJLSs4qWnjEj@faui48e.informatik.uni-erlangen.de>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 26 Feb 2024 17:14:12 -0800
Message-ID: <CAPDSy+5qHB0ih19aC=R5gM2j1z01x9goa=EXV=kYOj-1TaGE9g@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Ben Schwartz <bemasc@meta.com>, Michael Sweet <msweet@msweet.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000322362061252bfe4"
X-W3C-Hub-DKIM-Status: validation passed: (address=dschinazi.ietf@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-9.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: puck.w3.org 1rem3A-002HD1-2c 046f2d4cbd3d19cf400c813aaf900fa5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Link-local connectivity in Web browsers
Archived-At: <https://www.w3.org/mid/CAPDSy+5qHB0ih19aC=R5gM2j1z01x9goa=EXV=kYOj-1TaGE9g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51836
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>

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
>