Hi Martin,
On 17-Sep-22 07:31, Martin Thomson via Datatracker wrote:
Reviewer: Martin Thomson
Review result: Not Ready
As a bit of a preface here, I've been aware of this work for some time, but
have refrained from offering opinion. As liaison to the W3C, I felt like my
responsibility was to facilitate the conversation.
And many thanks for that.
However, as Barry has asked
me to do a review, I feel obligated to set that attempt at neutrality aside.
The biggest issue here is that this document is very much unwanted by its
target audience, as is its antecedent, RFC 6874. I share that concern.
In a way that's the whole point and exactly why it *should* be published
as an RFC.
Let's first dispense with RFC 6874. We (its authors, mainly) were careless
or naive, and so we ended up with a lot of stuff in there that was simply
unrealistic. So we should just forget about it.
Yes, we know that most of the browser writing community doesn't want this.
It's a feature request. Programmers very often don't want feature requests.
It's users that want them. True, this particular feature is not wanted by
the average user. But it's very much wanted by an important subset -
technical people who know that this will be needed for ops and diagnostic
reasons in future. Actually average users might also need it. You find
consumer products whose instructions tell you to browse to http://192.168.178.1
or something similar. A future product might tell you http://[fe80::1%eth0].
Just to underline one of the use cases, this is an *active* bug in Windows:
"In Windows 10, a WSD printer will have with a URL like this:
http://[fe80::822b:f9ff:fe6a:d7de%10]:80/WebServices/Device "
(from https://bugzilla.mozilla.org/show_bug.cgi?id=1759739, with
my follow-up at
https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c89 )
We deliberately kept the use cases in the draft at a high level, but they
are real enough. I really don't think it's acceptable for the browser
community to simply dismiss the requirement.
I have clear, strong indications from folks at three major browsers
(conveniently, I am at W3C TPAC this week and so was able to talk with a few
people directly on this topic; inconveniently, I've not had a lot of time for
this review) that this change to the URI specification is not just something
that they don't want to implement, but that it is not good for the Web. Public
communications from them will be somewhat more polite and circumspect, but it
has been made clear to me that this change is not wanted.
Since this URI is actually a LRI (local resource identifier) there is indeed
a meta-issue here, but one that already exists and seems entirely metaphysical.
"Not good for the web" is a strange statement for something that *explicitly*
has no meaning outside the host where it's used. Actually this is precisely
where RFC 6847 got itself into trouble, and rfc6874bis doesn't. From what
you say, it's unlikely that the people concerned have read the current draft
with care. At least one person already said off list that they haven't read
it. So this seems like hand-waving to me. I'd be interested to learn how
exactly this local format can damage the Web.
The IETF does occasionally publish specifications that don't end up being
implemented, but we usually look for signals that a protocol might be
implemented before even starting work. Here, we have a strong signal that a
specification won't be implemented.
So, you're happy that a requirement from people who define, implement and
manage the lower layers of the protocol stack can be refused on some
rather abstract argument?
Mark Nottingham asks the same question as
well as point 1 in [1]. (I don't personally find his second and third points
to be especially problematic given adequate consultation, but even there, there
are a few concerns that I will outline below.)
I do want to give due credit to the authors - Brian in particular - for being
very open and forthright in their consultation with the affected constituency.
They have been proactive and responsive in a nearly exemplary fashion.
Overall, I think that it would be better for the IETF to declare RFC 6874 as
Historic(al).
That's kind of irrelevant. As far as the use cases go, that would change
nothing. The users would be left with nothing.
There might be some residual value in RFC 4007 from a diagnostic
perspective,
Er, diagnostic use via ping is a tiny part of the value of RFC 4007.
RFC 4007 is fully supported by the POSIX and WinSock APIs and is used
by any piece of software that needs to make use of link local
addresses. I've written some such software myself and it works well.
but the use of zone identifiers in URIs seems fundamentally
incompatible with the goals of URIs.
Metaphysically, you are correct, of course: http://[fe80::1%eth0]
is not a URI, it's an LRI. But so is http://192.168.178.1, so
this train left the station 20 years ago. Would it help if the
draft pointed this out?
I do recognize that the Web and HTTP is not the only protocol affected by this
sort of change. The goal is to change all URI types. However, I believe that
HTTP is pretty important here and I have a fair sense that the sort of concerns
I raise with respect to HTTP apply (or should apply) to other schemes.
Well, yes, but the "U" versus "L" distinction will stand.
---
There are a few technical concerns I have based on reviewing the draft. Some
of these - on their own - are significant enough to justify not publishing this
document.
Inclusion of purely local information in the *universal* identity of a resource
runs directly counter to the point of having a URI. This creates some very
difficult questions that the draft does not address.
I got rapped over the knuckles whenever I conflate "U" with "Universal",
since it actually stands for "Uniform", but OK.
The other possible conflation is with "Unique". Note that http://192.168.178.1
is far from unique. Millions of instances exist. http://[fe80::1%eth0]'
is no different in that respect.
For instance (1), the Web security model depends on having a clear definition
for the origin of resources. The definition of Origin depends on the
representation of the hostname and it relies heavily both on uniqueness
(something a zone ID potentially contributes toward) and consistency across
contexts (which a zone ID works directly against). Now, arguably the identity
of resources that are accessed by link-local URIs don't need and cannot
guarantee either property, but this is an example of the sorts of problem that
needs to be dealt with when local information is added to a component that is
critical to web security.
Yes, but when we tried to address this in RFC 6874 by requiring the local part
to be deleted on the wire, the implementers (very reasonably) told us we were
silly. Should we state that the Zone ID should be disregarded for security
purposes?
The thing is, like it or not, when two hosts communicate via their link-local
addresses, using any protocol whatsoever, they have implicitly formed
a limited domain. (Didn't think of that for RFC 8799.)
For instance (2), in HTTP and several other protocols, servers depends on the
host component - as it appears in the URI - to determine authority. If there
is no rule for stripping the zone ID from URIs, servers hostname checks will
depend on the client. That exposes link-local servers to information that they
need to filter out. Some might not be prepared to do that.
When they receive a link-local packet, they know which interface they received
it on, but they have by definition no way to validate the zone ID, so certainly
they either have to take it on faith or ignore it. I don't see a problem
with ignoring it, but there would be code changes needed to do so.
Hostname checks
are critical for security, especially the consistent treatment of the field
across different components like serving infrastructure, web application
firewalls, access control modules, and other components.
Sure. That's exactly why we wanted to strip it in 4874, but implementers
said no. So it needs to be ignored at the server side. We should say that
somewhere in the document.
This is a non-backwards-compatible change to RFC 3986. The only issue related
to this that is addressed in the draft is the question of document management -
this updates RFC 3986 - but surely there are other concerns that might need to
be addressed. I see some effort to address software backwards-compatibility in
discussion threads, but I found very little in the draft itself.
It seems like a pretty standard legacy problem to me. It will only work on
updated systems, and it will fail on legacy systems.
The configuration of zones on a machine is could be private information, but
this information is being broadcast to servers.
Well, unicast actually.
In HTTP, that is in Host
header fields; on the Web, in document.location. This information might
contribute significant amounts of information toward a fingerprint. I
appreciate that the stripping of zone ID was never implemented, but it is a
useful feature.
But as noted above, vigorously rejected by implementers (and actively
damaging to the CUPS use case).
Arguments in Section 5 depend on the zone IDs being hard to guess, but that
isn't true. Zone IDs are - in practice - low entropy fields.
Well, they vary, and in some cases could be guessed from the MAC address.
They are not the main defence against scanning attacks.
More critically,
they are fields that are sent to servers.
Yes, but only to very local servers, and not actually very useful in themselves.
Zone ID size is not bounded - most implementations will have a size limit on
the authority or host portion of a URI (256 octets is sufficient for current
names), but the implication is that Zone IDs could be arbitrary length.
That's a defect in RFC 4007 that we can't do much about, but we should
note it.
Though percent-decoding is not likely to be a concern from a specification
perspective (the operative specification from the browser perspective does not
apply pct-decoding to a v6 address [2]), what work has been done to verify that
a zone ID won't break existing software?
That's a negative I can't prove. However, my patched version of wget didn't break
the server in my FritzBox, which simply did what I expected it to do.
Regards,
Brian
[1] https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/
[2] https://url.spec.whatwg.org/#concept-host-parser
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
