OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] GCS Spoofing


Hi All,

I've been following the discussion and find it very interesting.  I'm
starting to wonder if we are delving into areas that need to be fixed
generally instead of just in the context of XRI.  I'd also like to know
what sort of effort the folks involved expect this sort of analysis to
take.  This topic is sounding very time-consuming to me.  

So I guess I'm asking if (1) XRI is the right place to do this level of
analysis and specification and (2) if we decide XRI is the right place,
how long might this take?

Mike

>-----Original Message-----
>From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] 
>Sent: Tuesday, September 20, 2005 10:00 AM
>To: Bryan Rasmussen
>Cc: xri@lists.oasis-open.org
>Subject: RE: [xri] GCS Spoofing
>
>Bryan: 
>
>I was a bit concerned with two perhaps pathological cases: 
>
>(1) Not all fonts displays the code point the same. 
>     For example, Simplified Chinese, Traditional Chinese, 
>Japanese and 
>     Korean share the same code point with different visual
>representation. 
>     This means that, potentially, we would have to go through 
>     the visual representation of the code point with bunch of fonts.  
>     Perhaps this does not apply to GCS characters, but 
>     I am not sure yet -- thus precaution. 
>(2) Combined characters: Just off the top of my head, I could think of 
>     something like 'x' overprinted with '+', which would look like an
>asterisk. 
>     What about '|' vertical line with '-' minus overprinted? 
>     We can think of up to three codes combined. And, of course, 
>     'a' overprinted with a circle is a classic example. 
>     Can we find all of them just by going through the table? 
>
>Those were my concern. 
>
>Fortunately, solving the problem of look alkies for GCS character is 
>pretty easy with the help of client agent. Even though we many not 
>be able to list all the look-alikes, the client agent definitely know 
>what is the legitimate GCS character. This is not the only way, 
>but color coding the GCS chars would suffice. If the user knows 
>that the GCS chars are going to be blue, and others are black, 
>all the look-alike-character-attack will fail. (Note: underline or 
>something like that will not work because it can be 
>potentially created 
>by character combinations.) 
>
>Nat
>
>> -----Original Message-----
>> From: Bryan Rasmussen [mailto:brs@itst.dk] 
>> Sent: Tuesday, September 20, 2005 4:26 PM
>> To: Sakimura, Nat
>> Cc: 'xri@lists.oasis-open.org'
>> Subject: SV: [xri] GCS Spoofing
>> 
>> I'm not sure that I understand this:
>> 
>> 1. it isn't the case that the number of look-alikes are 
>> unknown, thus I think it would be relatively unlikely that we 
>> forget some. sure, if it was off the top of the head one 
>> might forget, but not going through a chart of characters and 
>> making a list of each look-alike. 
>> 2. People already trust look-alikes, thus the problem with 
>> phishing. If they stop trusting look-alikes then we might 
>> have some case for not disallowing look-alikes.
>> 3. The question is not whether they trust look-alikes anyway, 
>> but whether they trust urls/uris as being what they read them 
>> to be. I think we might actually want people to trust 
>> urls/uris as being what they read them to be because 
>> otherwise there will have to be a lot of extra work for users 
>> to figure out what each address they are looking at actually is. 
>> 4. If we do manage to miss some, well then that will mean 
>> they should not trust any xri with one of the missed 
>> look-alikes in it. A very useful part of any security process 
>> is narrowing the target.
>> 
>> Cheers
>> Bryan Rasmussen
>> 
>> -----Oprindelig meddelelse-----
>> Fra: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
>> Sendt: 20. september 2005 05:54
>> Til: Drummond Reed; Chetan Sabnis
>> Cc: xri@lists.oasis-open.org
>> Emne: 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
>> > 
>> > 
>> > 
>> 
>> ---------------------------------------------------------------------
>> 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 
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]