Re: [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

I haven't been following closely, but perhaps someone might take a moment
to explain why defining a new scheme isn't preferable to changing the
parsing rules for old schemes?

On Sat, Mar 25, 2023 at 7:57 PM Martin Thomson <[email protected]> wrote:

> Despite sessions being busy, my extrasessionary schedule is light.
>
> Would 16:30 Tuesday work for people?  A side meeting room is presently
> available at that time.
>
> On Sun, Mar 26, 2023, at 11:36, Martin J. Dürst wrote:
> > I just happened to bump into Martin Thomson at the IETF hackathon in
> > Yokohama. We discussed this draft, and thought we might be able to
> > organize a little side meeting to discuss the issues and hopefully also
> > make some progress. We know that Brian is remote, but we will try to
> > have a setup where he can participate remotely.
> >
> > We welcome everybody from the IPv6 and URI side who is interested;
> > that's the reason for cross-posting. Martin Thomson is way more busy
> > than me, so I'm letting him (or anybody else) propose some time slots.
> >
> > Regards,   Martin.
> >
> > On 2023-03-16 22:54, Francesca Palombini wrote:
> >> Martin: thank you very much for this review. I have looked at the
> following responses as well, and I am not sure that there was ever a
> conclusion to the mail thread, although I can see that Brian did try to
> make modifications and clarifications in the text as much as possible.
> Murray has balloted DISCUSS following your review and subsequent
> discussion, and I support his DISCUSS in my ballot (1). We will talk about
> it today. If you have any insight about Murray’s question: Do any of the
> communities rejecting it have a preferred alternative for achieving the
> stated goal? It would be helpful.
> >>
> >> Thanks,
> >> Francesca
> >>
> >>
> >>    1.
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/ballot/
> >>
> >> From: last-call <[email protected]> on behalf of Martin
> Thomson via Datatracker <[email protected]>
> >> Date: Friday, 16 September 2022 at 21:32
> >> To: [email protected] <[email protected]>
> >> Cc: [email protected] <
> [email protected]>, [email protected] <[email protected]>,
> [email protected] <[email protected]>
> >> Subject: [Last-Call] Artart last call review of
> draft-ietf-6man-rfc6874bis-02
> >> 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.  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.
> >>
> >> 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.
> >>
> >> 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.  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).  There might be some residual value in RFC 4007 from a
> diagnostic
> >> perspective, but the use of zone identifiers in URIs seems fundamentally
> >> incompatible with the goals of URIs.
> >>
> >> 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.
> >>
> >> ---
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.  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.
> >>
> >> 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.
> >>
> >> The configuration of zones on a machine is could be private
> information, but
> >> this information is being broadcast to servers.  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.
> >>
> >> 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.  More
> critically,
> >> they are fields that are sent to servers.
> >>
> >> 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.
> >>
> >> 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?
> >>
> >> [1]
> https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivsCho_A/
> >> [2]
> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-cb4f75973d92a246&q=1&e=1a8ad5bf-5551-4142-b354-2f4d049e530a&u=https%3A%2F%2Furl.spec.whatwg.org%2F%23concept-host-parser
> >>
> >>
> >> --
> >> last-call mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/last-call
> >>
> >>
> >> _______________________________________________
> >> art mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/art
> >
> > --
> > Prof. Dr.sc. Martin J. Dürst
> > Department of Intelligent Information Technology
> > College of Science and Engineering
> > Aoyama Gakuin University
> > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > 252-5258 Japan
>
> _______________________________________________
> art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/art
>


-- 
https://LarryMasinter.net  https://interlisp.org

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art