Re: Link-local connectivity in Web browsers

On Mon, Feb 26, 2024 at 09:19:48PM -0800, David Schinazi wrote:
> > 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/

But i can not remember having seen any implementations/use being mentioned
where at least the client is not a browser but some other application using
URLs, for example programmatically. Neither was this considered i think
in Murray's DISCUSS.

> 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.

Maybe "browser-cores" or "platforms" - i am sure ther must be a fitting term.
I don't want to diminish the work all the differnt
browser do on top of those shared cores. It's a good model unless it
comes to ugly issues like what we run into here.

> 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.

Well, the security issues would be where we need the HTTPS community
input, i wouldn't know. And yes, the use-cases is where we folks from
the "crappy network setup side" need to collect more info.

But remember that my core thinking in this discussion is that scoped
link-local addresses are a core underutilized part of the IPv6 architecture,
and whenever we have put our mind to it, they did help us to improve/simplify
solutions over IPv4. But to be able to do that in the context of HTTPS
based user-machine or machine-machine communication, we first need to
come to a solution how we can use them in URLs. Only then i think will
we have enough of an architecture that application solutions using
e.g.: REST APIs could start thinking how to benefit for link-local addresses.

In other word:I reject the notion that we need to show overwhelming business
need on browsers to justify that scoped IPv6 addresses in URLs need to
be standardized. I do agree though that browsers only need to implement
such a standing if and when they have sufficient business case. And i think
we need to do our best to ensure we do put into the standard the best
technical solution - as we understand it.

> 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.

Agreed.

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

-- 
---
tte@cs.fau.de

Received on Tuesday, 27 February 2024 17:10:37 UTC