[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] GCS Spoofing
Wil, My pleasure. Thank YOU for both raising and tackling this issue, which could become very important in the future of XRI adoption. We're trying to apply "lessons learned" at every other level of Internet identifier infrastructure (DNS, HTTP URI, other URI, URN, IRI) and my feeling is that we should definitely apply the lessons learned of IDN. I look forward to seeing the characters you collect, together with your proposal for the best way we should deal with them. =Drummond -----Original Message----- From: William Tan [mailto:wil@dready.org] Sent: Monday, September 19, 2005 10:53 AM To: Drummond Reed Cc: 'Sakimura, Nat'; 'Chetan Sabnis'; xri@lists.oasis-open.org Subject: Re: [xri] GCS Spoofing I agree that Nat has an excellent point - the spoofing problem buried in Unicode's massive repertoire has no silver bullet solution, user education and application-level intelligence is definitely needed. I have started collecting the characters, and will be done by tomorrow. I will then post the results to this list. Be warned, there is a whole bunch of them, as Nat said, and some are gray areas. Drummond, thanks for translating the problem statement into the wiki proposal page. wil. Drummond Reed wrote: > Nat, this is an extremely good point. I agree with you, that's the > full-scale solution. > > However, I think that Wil's suggestion that we could actaully block the > direct look-alike characters that would result in an "IDN-like" semantic > attack on the GCS characters and other XRI delimiter characters (focusing > particularly on @, =, +, !, *, and /) is still one we should look at > closely. > > Even if these would be blocked/converted by NFKC, a semantic attacker would > ignore that rule. So Wil's suggestion is that we disallow all Unicode > homographs for the XRI delimiters from the IRI iunreserved set might make it > easier for others in the XRI resolution chain (such as resolvers and > browsers) to block such an attack. > > Wil (and everyone), on Friday's TC call it was agreed to add this issue as > Issue #8 (IRI Authority Spoofing) Syntax change management page > (http://www.oasis-open.org/committees/download.php/11852/xri-syntax-v2.0-cd- > 01.pdf). The proposal page is at: > > > http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I8IriAuthoritySpoofing > > Wil, the TC members wanted to know how many Unicode characters would be > involved (i.e., what's the scope of eliminating these homographs at the XRI > spec level?) And how long do you estimate it would take for you to create a > list of these characters that could be excluded from the iunreserved > production? > > Thanks - this was indeed a good catch. > > =Drummond > > -----Original Message----- > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > Sent: Sunday, September 18, 2005 9:48 AM > To: Chetan Sabnis > Cc: xri@lists.oasis-open.org > Subject: RE: [xri] GCS Spoofing > > Actually, when it comes to internationalized characters, there are whole > bunch of possibility on Visual-Look-Alike base spoofing. Forcing NFKC > normalization would ease the problem a bit, but far from completely. > IMHO, it has to be dealt with trust and reputation mechanism being > coupled with client side support for the user so that user can view the > trust level easily. > > Nat > > >> -----Original Message----- >> From: Chetan Sabnis [mailto:chetan.sabnis@epok.net] >> Sent: Friday, September 16, 2005 11:30 PM >> Cc: xri@lists.oasis-open.org >> Subject: Re: [xri] GCS Spoofing >> >> >> Great find. I think the TC needs to address this in order >> for XRIs to be used as links in an email, as URIs would be >> used in an email today. >> The authority accessed by the resource needs to be be >> well-understood based on looking at the XRI if XRIs are >> indeed intended for human viewing. I think this is not a >> GCS-only issue. It certainly seems like the potential is >> there to spoof authorities in private cross-reference domains as well. >> >> Forgive my ignorance, but does the IRI spec address this? It >> seems like there might be some guidance there. >> >> Chetan >> >> William Tan wrote: >> >> >>> The ABNF for XRI accommodates two types of authority: XRI authority >>> and IRI authority. >>> An XRI authority must begin with a GCS character: "!", "=", >>> >> "@", "+" >> >>> or "$". However, if the XRI reference begins with a >>> >> character that is >> >>> visually indistinguishable from one of the GCS characters, and the >>> code point is allowed in the the "iunreserved" production, >>> >> a machine >> >>> processor would treat it as an IRI authority. This may be a >>> >> cause for >> >>> concern since it opens the door for spoofing. For example, >>> >> an actual >> >>> XRI may be: xri://@paypal*services/send-money >>> >>> and it could be spoofed (although not exactly) by using: >>> >>> xri://@paypal*services/send-money/sub.bad-domain.com/trustme.html >>> >>> And the "@" sign above is U+FE6B (small commercial at), "*" >>> >> is U+FE61 >> >>> (small asterisk), and the 4th and 5th "/" are U+2215 >>> >> (division slash). >> >>> In effect, the XRI would be interpreted as having an IRI >>> >> authority (an >> >>> IDN) of: "@paypal*services/send-money/sub.bad-domain.com". This is >>> possible largely because IDNA allows the slash-like character in an >>> IDN label, giving rise to the possibility of syntax spoofing. And >>> because sub domains appear to right of their parent domains, the >>> malicious domain can be created as a third (or higher) level sub >>> domain so that it is outside of the registry's control. >>> >>> This is merely a subclass of syntax spoofing homograph >>> >> attacks on IDN >> >>> which applies to XRIs. >>> >>> I'm not sure where is the best place to address it, or if it would >>> even be deemed a problem that the XRI TC would want to solve. If we >>> do, there are at least ways to go about fixing it, at the >>> >> syntax level >> >>> (i.e. by mapping or limiting the use of GCS characters) or as a >>> recommendation for XRI clients to disallow or warn the user of >>> GCS-like characters appearing at the beginning of an XRI reference. >>> >>> wil. >>> >>> >>> >> --------------------------------------------------------------------- >> >>> To unsubscribe from this mail list, you must leave the >>> >> OASIS TC that >> >>> generates this mail. You may a link to this group and all >>> >> your TCs in >> >>> OASIS >>> at: >>> >>> >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS >> TC that generates this mail. You may a link to this group >> and all your TCs in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >> oups.php >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]