Re: Link-local connectivity in Web browsers

[David Schinazi <[e-mail]>]

On Mon, Feb 26, 2024 at 7:04 PM Toerless Eckert <[e-mail]> wrote:

> On Mon, Feb 26, 2024 at 06:37:19PM -0800, David Schinazi wrote:
> > 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.
>
> Correct me if i am wrong, but is it not true, that this discussion took
> only place in the context of browsers, but not the broader set of software
> that is using HTTP(S) even programmatically such as in REST APIs ?
>

No, that discussion happened in the context of HTTP and URIs. It was not
specific to browsers. You can search for curl and wget in these threads to
get examples of non-browser software. For example:
https://mailarchive.ietf.org/arch/msg/ipv6/lLWV1WVmUxqN42fYQ-dlnI2d70U/

Is it not also true, that we have with browser a particularily difficult
> industry because it has convered to very few browser cores, namely
> chrome and firefox, which are re-used by a much larger number of
> significantly
> used browser in the industry, so effectively only two implementers have a
> real
> say when it comes down to implementation ?
>

I'm sure the folks over at Apple would have opinions about that statement,
but yes there is a small number of browsers today. That is a reality.

In addition: I have heard from one implementation attempt, and i can
> agree that these two browser cores are very complex. However, i am
> not persuaded, that this necessarily equals complexity in the standards
> process modelling that you claim to exist. After all, i think that
> was some good amount of examples here on the thread that the existing
> origin model does already carry security issues with it, that are simply
> being ignored because they are seemingly not significantly exploited.
>
> Aka: Given how the IETF has all of networking based on IPv6 at the
> network layer, and we can not change that to eliminate link-local
> addresses, and we also can not expect all use-cases to use (m)DNS
> (which also has other issues as we discussed), i think it is quite
> important to at least outline the standardization/security implications
> first and independent of the likely implementation effort so that
> we can judge them.
>

I think thinking through such security implications and writing them down
is always a good idea. I look forward to reading your draft! I'm also
curious to hear about these use-cases that cannot be solved by mDNS.

We have a lot of smaller areas in the industry, where smaller use-cases
> have resulted in custom setups of browsers, so i do not even agree
> to the assesment you and Murray do that WHATWG is the only relevant
> candidate implementers circle.
>

I don't understand what you mean. I only mention WHATWG in that they own
the URL spec used by browsers.

But at this point I think we've reached the limits of email back-and-forth,
and might benefit from verbal communication, I'll ask for some agenda time
to present this draft in Brisbane and we can pick this up there.

David

Cheers
>     Toerless
>
> > David
> >
> >
> > On Mon, Feb 26, 2024 at 6:27 PM Toerless Eckert <[e-mail]> 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 <[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]
> > >
>
> --
> ---
> [e-mail]
>