Re: Link-local connectivity in Web browsers

[Toerless Eckert <[e-mail]>]

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 <[e-mail]>
> Sent: Thursday, February 22, 2024 5:14 PM
> To: Michael Sweet <[e-mail]>
> Cc: David Schinazi <[e-mail]>; HTTP Working Group <[e-mail]>
> 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
> 

-- 
---
[e-mail]