Re: Link-local connectivity in Web browsers

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
>