Re: David/*: Origin concept Q (was: Re: Link-local connectivity in Web browsers)

Resending, because i am still unclear how the zone in a URL would be a problem for
the "irigin" concept. It would neither be in the TLS server_name field nor would it
be in any HTTP header - or for that matter in any other URL header, it would
solely be a local element.

Can someone please elaborate to me how this results in actual issues to the
origin concept ?

Cheers
    Toerless

On Thu, Feb 22, 2024 at 03:07:12AM +0100, Toerless Eckert wrote:
> On Wed, Feb 21, 2024 at 05:26:42PM -0800, David Schinazi wrote:
> > Hi Toerless,
> > 
> > The origin is the scheme, hostname, and port of the server - not of the
> > client. The client gets it from the URI and it is then sent to the server
> > using (amongst other things) the HTTP Host header. This allows (amongst
> > other things) the server to host multiple domains on the same port. This
> > requires the name to be meaningful to the server.
> 
> You can only set up multiple domains on the same address/port socket of a
> server when the client has a URL with a domain name. If it only has an
> IP/IPv6 address, then it can neither set the HTTP Host: header to something
> more useful than the IP address, nor can it set the TLS SNI. Aka: What you say does
> already not work for IP/IPv6 addresses, which are supported in all browsers,
> so the zone_id does not create any additional problem.
> 
> Am i missing something ?
> 
> You said "amongst other things". What is another most relevant issue ?
> 
> Cheers
>     Toerless
> 
> > 
> > David
> > 
> > On Wed, Feb 21, 2024 at 5:04 PM Toerless Eckert <tte@cs.fau.de> wrote:
> > 
> > > On Tue, Feb 20, 2024 at 08:53:11PM -0800, David Schinazi wrote:
> > > > Hi HTTP enthusiasts,
> > > >
> > > > [I'm creating a separate thread from [1] to avoid further cross-posting.]
> > >
> > > Personally i think a topic that equally affects two WG is perfect for
> > > cross-pposting,
> > > because without it, we have to throw information back and forth and likely
> > > miss
> > > important input from the other side. RFC6874(bis) is an example of what
> > > happens then.
> > > But i understand there is some history of (misguided ?) people considering
> > > cross-posting evil.
> > >
> > > Thanks for for writing the draft. I have an ongoing doc with comments etc.
> > > for it,
> > > hopefully can finish soon.
> > >
> > > In general we do of course need to do everything we can do with (m)DNS,
> > > but i fear
> > > several cases people wrote rfc6874 for will not work with DNS. I also think
> > > those cases are not well communicated, and they certainly are for the
> > > overall
> > > business of the core internet browsers not very large. Nevertheless, that
> > > business
> > > side i think shouldn't stay in the way of an RFC like rfc6874(bis) because
> > > everybody
> > > is free to ignore when threre is not enough business, and there are more
> > > lightweight
> > > implementation options i think, such as plugins. But technical
> > > insufficiencies on the
> > > other hand need to be be fixed so we have the best option if and when it
> > > is needed.
> > >
> > > To that end one high level education question about the origin concept:
> > >
> > > It seems one of the expectations of origin is that you expect for the
> > > hostname
> > > portion of URLs (or at least https URLS) to be of more than local
> > > significance
> > > to uniquely identify an http(s) entity (ideally globall unique).
> > >
> > > What is the most simple and widely used example for this, e.g.: an example
> > > of
> > > something breaking when that hostname portion is not unique ? Is this
> > > already a problem
> > > in the face of two parties or just three or more ? Pointer to any existing
> > > example text
> > > would be fine.
> > >
> > > I am asking, because there are a lot more than link-local-ipv6 addresses
> > > that
> > > do not have global significance. Most widely used of course are IPv4
> > > RFC1918
> > > addresses. So i wonder why there wouldn't be the same origin issue about
> > > origin
> > > with them.
> > >
> > > E.g.: i am running a client side javascript and my system has an rfc1918
> > > address
> > > (192.168.1.2), my javascript pass this ip address back to the web server
> > > in the internet,
> > > that server know what to do with it - unreachable. And of course that web
> > > server
> > > could get millions  of clients all with the same rfc1918 address
> > > 192.168.1.2 - and
> > > they're all different entities/origins.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > > Some of you might have seen various discussions around the use of IPv6
> > > > link-local addresses (such as fe80::1234%eth0) in Web browsers. In
> > > > particular, RFC 6874 had added a way to represent these addresses in
> > > URIs.
> > > > I wasn't involved back then but the published RFC ended up being
> > > something
> > > > that was quite complex to implement safely in browsers, so it didn't get
> > > > wide support. More recently, draft-ietf-6man-rfc6874bis attempted to
> > > create
> > > > a new URI format for such addresses. Oddly, I didn't see it ever
> > > discussed
> > > > on this list. That draft had other issues in terms of how it handled the
> > > > Web security model, and ultimately there hasn't been consensus to publish
> > > > it.
> > > >
> > > > I think it would be great for us to obsolete RFC 6874 and instead
> > > recommend
> > > > a solution that already works with every browser today: mDNS. So I wrote
> > > a
> > > > draft that does that:
> > > >
> > > >
> > > https://datatracker.ietf.org/doc/draft-schinazi-httpbis-link-local-uri-bcp/
> > > >
> > > > I'd love to get your thoughts on it!
> > > >
> > > > Thanks,
> > > > David
> > > >
> > > >
> > > > [1]
> > > https://lists.w3.org/Archives/Public/ietf-http-wg/2024JanMar/0111.html
> > >
> > > --
> > > ---
> > > tte@cs.fau.de
> > >
> 
> -- 
> ---
> tte@cs.fau.de
> 

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

Received on Saturday, 24 February 2024 02:43:46 UTC