Re: Link-local connectivity in Web browsers

[Toerless Eckert <[e-mail]>]

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 ?

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 ?

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.

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.


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]