Re: Link-local connectivity in Web browsers

[Toerless Eckert <[e-mail]>]

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 <[e-mail]> 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 <[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]
> >

-- 
---
[e-mail]