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

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 <last-call-bounces@ietf.org> on behalf of Martin Thomson via Datatracker <noreply@ietf.org>
>> Date: Friday, 16 September 2022 at 21:32
>> To: art@ietf.org <art@ietf.org>
>> Cc: draft-ietf-6man-rfc6874bis.all@ietf.org <draft-ietf-6man-rfc6874bis.all@ietf.org>, ipv6@ietf.org <ipv6@ietf.org>, last-call@ietf.org <last-call@ietf.org>
>> 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
>> last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
>> 
>> 
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> 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

Received on Sunday, 26 March 2023 02:57:35 UTC