search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
322 stars 55 forks source link

updated URI syntax for IPv6 link-local zone identifiers #774

Closed ekline closed 1 year ago

ekline commented 1 year ago

Wotcher TAG!

I'm requesting a TAG review of "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" (draft-ietf-6man-rfc6874bis).

Explainer

From the abstract:

This document describes how the zone identifier of an IPv6 scoped address, defined as in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax and Internationalized Resource Identifier specifications (RFC 3986, RFC 3987) accordingly, and obsoletes RFC 6874.

This IETF draft proposes updating URI/IRI IP-literal syntax as follows:

 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

 ZoneID = 1*( unreserved )

 IPv6addrz = IPv6address "%" ZoneID

in order to help ensure adoption within browsers and other tools. One goal is to ease use of IPv6 link-local address literals in browsers when/where on-link device configuration is being performed.

This is a clarification and, importantly, simplification of RFC 6874.

Specification

The latest version of this draft can be found at https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis.

Tests

None of the kind TAG might expect. With respect to implementation, at a minimum, a patch to wget to support this change exists.

User research

Section 2 and Section 4 of draft -02 capture observations of IP address literal parsers and use (or lack thereof) currently. This forms part of the motivation for this document.

Security and Privacy self-review

Section 5 of draft -02 covers security and privacy considerations.

Primary contacts

Organization

This document is a product of the IETF IPv6 Maintenance working group (6man).

Key pieces of review

This document updates the IP-literal ABNF specification of URIs/IRIs. As such, any feedback on the correctness or additional thoughts on the document in general would be very much appreciated.

External trackers

Further details:

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify becarpenter, furry13, ekline

ekline commented 1 year ago

@becarpenter @furry13

becarpenter commented 1 year ago

I'll add that recently I wrote a javascript mechanism to demonstrate that although theoretically one can script a scanning attack to discover link-local addresses via URLs with link-local address literals, it's impracticably slow (as suggested in the draft's Security Considerations). Even so, I won't publish the script. (The technique would also be able to discover any kind of IP address; it's by no means limited to IPv6 link-local.)

torgo commented 1 year ago

Hi @ekline just FYI we're looking at this and we hope to get back to you soon.

ekline commented 1 year ago

Thank you. I've been slow to advance things on my end, but I do believe we should understand the W3C position before we take any irreversible steps. =)

Much appreciated, and happy end-of-year holiday season (already?!).

becarpenter commented 1 year ago

Be sure to check the latest version of the draft, there were significant updates since this issue was opened: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-04.html There's also a very new issue noted at https://mailarchive.ietf.org/arch/msg/ipv6/G4pOCYDGXo-sYtzLxcooQP__WzU/

martinthomson commented 1 year ago

This thread might provide some useful input: https://mailarchive.ietf.org/arch/msg/ipv6/lkrJjMUwZrUC7jYAo2mYCS4fpeA/

becarpenter commented 1 year ago

FYI, the latest (-04) version was intended to respond to Martin's points, among other Last Call comments.

becarpenter commented 1 year ago

New version today : https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html There's one change, adding a note that zone IDs with upper case letters won't work. (That's an issue we can't fix, due to a shortfall in RFC4007.)

ylafon commented 1 year ago

I looked at it, and wonder about its use to discover private information about the shape of the local network, especially when zones are interfaces. Also the use of % as the delimiter for the zone id means that you should either rewrite the entire abnf, or exclude all abnf-generated parsers. Having specific exclusions from the common use of % in URIs means specific code that has to be maintained and likely ways to abuse old parsers that would consider the % as the usual escape mechanism. In both case, this is not desirable.

becarpenter commented 1 year ago

About the malicious discovery issue, such an attack is impractical. This is discussed at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-6-5 . I tried writing an address-scanning script (exploiting the fact that Windows supports a default Zone ID) and tested it on Firefox, Chrome and Edge. It's impractically slow since the search space is 2**64. (I have no intention of publishing my script and my Javascript skills are weak, but if you read the following thread, you will get the gist: https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&q=scripting%20attacks )

The draft does update the ABNF and (as required by IETF process) we've validated the result. Most parsers don't seem to be written that way, however.

ylafon commented 1 year ago

Hi, we discussed the issue again during our last teleconference. The issue of malicious discovery is still there as it won't start with a brute-force attack, but more on probable zone names (especially if it involves interface names). Also the use of % as a delimiter is still seen as problematic as it is the escape delimiter and can lead to exploit of existing parsers that are not careful about when to apply unescaping. The lack of implementation support in browsers is another source of concern, it would be good also to get agreement within IETF, especially with the group in charge of maintenance of rfc3986. Thanks

becarpenter commented 1 year ago

Hi,

(I am blind copying this to the IETF 6MAN WG. Be careful when replying.)

On 25-Nov-22 02:10, Yves Lafon wrote:

Hi, we discussed the issue again during our last teleconference. The issue of malicious discovery is still there as it won't start with a brute-force attack, but more on probable zone names (especially if it involves interface names).

That is correct and is discussed at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-6-6 . This theoretical risk has always existed for IPv6 literal addresses in URLs and is not specific to link-local addresses. The primary defence is the 64-bit size of the interface identifier space, which is impracticably large for a brute force search. This is one reason why the IETF now recommends pseudo-random interface identifiers, and has little to do with link-local addresses. (If you're looking for a practical brute force search, try starting at https://192.168.178.1/ .)

Given that, this is hardly an argument against supporting Zone IDs.

Also the use of |%| as a delimiter is still seen as problematic as it is the escape delimiter and can lead to exploit of existing parsers that are not careful about when to apply unescaping.

Why is there an "exploit" here? The worst that can happen is that a server rejects the URL. We discuss this eventuality in the draft at https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-05.html#section-4-1 , and it's really a feature, not a bug.

The lack of implementation support in browsers is another source of concern, it would be good also to get agreement within IETF, especially with the group in charge of maintenance of rfc3986.

We're trying to provide the egg half of the chicken-and-egg dilemma. It will be for each browser implementer to decide whether to proceed with the chicken. Of course the normal cross-area review process is under way in the IETF.

Thanks for the update.

 Brian

Thanks

— Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/774#issuecomment-1326433378, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMKET5QCMHVPQNBQBM3IDTWJ5SMLANCNFSM6AAAAAAQK45ROU. You are receiving this because you were mentioned.Message ID: @.***>

torgo commented 1 year ago

Hi folks - As discussed in today's TAG breakout. We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is lack of implementer support, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved.

becarpenter commented 1 year ago

Erik, et al.,

Please see the attached response from W3CTAG. Their remaining comments are not new and have been addressed previously:

a) The necessity to use "%" is unfortunate but inevitable, due to the fact that it was defined as the delimiter by RFC 4007 in 2005 and has been embedded in operating systems and the socket API ever since. It was a bad choice but we are stuck with it, and the proposed ABNF is parsable (as illustrated by the corresponding patch to WGET). We have not heard from any browser implementer that it cannot be parsed.

b) The "lack of implementer support" is not unusual for advancement to an IETF Proposed Standard; it is only when a document is advanced to Internet Standard that it becomes an issue. In fact, this "bug" has been re-activated for FireFox. **

Therefore, there are no further updates to the draft at this time.

As far as I know, there is no group in the IETF "in charge of RFC3986" apart from the IESG. May we proceed?

Regards Brian Carpenter

** https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c94

On 20-Dec-22 21:33, Daniel Appelquist wrote:

Hi folks - As discussed in today's TAG breakout https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/12-19-agenda.md. We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is 2005, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved.

— Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/774#issuecomment-1359002511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMKET6RRHSVOWSMTNKPA4TWOFVNHANCNFSM6AAAAAAQK45ROU. You are receiving this because you were mentioned.Message ID: @.***>