[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] GCS Spoofing
Well, I agree to the point, but I am not quite sure if we can effectively list all look-alikes. If we start doing that, people will trust the "look-alikeness" and this means that we have to really careful that we exclude all the look-alikes. There will be some subjective judgement involved as well. This is not a trivial task. Is there a good way of doing it? Nat > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Monday, September 19, 2005 2:41 PM > To: Sakimura, Nat; 'Chetan Sabnis' > Cc: xri@lists.oasis-open.org > Subject: RE: [xri] GCS Spoofing > > 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-s > yntax-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_workgr > oups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]