Re: Link-local connectivity in Web browsers

Hi Toerless,

As discussed in previous email in the quite lengthy threads about
draft-schinazi-httpbis-link-local-uri-bcp, draft-carpenter-6man-zone-ui,
and draft-ietf-6man-rfc6874bis, you can't magically change how the origin
is used without considering all of the numerous places where the origin is
used, especially for security decisions. That means significant
standardization work, and also significant implementation work.
Implementers of HTTP have indicated their disinterest in performing that
work.

David


On Mon, Feb 26, 2024 at 6:27 PM Toerless Eckert <tte@cs.fau.de> wrote:

> 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 <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
> > >
>
> --
> ---
> tte@cs.fau.de
>