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