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


Thanks very much William. This is a great work. 
My previous email was before looking at this mail. 

If we were to ban all the look alikes, I would add Japanese 'ten' as 
another candidate for GCS '+' look alike. 
Perhaps, character 'soil' is another candidate. Would hiragana 'no' 
be a look alike for '@' ? It would not be for a Japanese, but it may be 
for other people. And ... banning these characters would defeat the 
purpose of having international characters in XRI, because somebody's 
name would no more be able to be expressible by XRI. 

I agree with William that this "restriction problem" should not be 
a part of the spec. I would much rather leave it as the recommendation 
for the client applications. As I have written in the previous mail, 
it would be rather trivial for the client software to make the real GCS 
characters discernable for the user. 

Nat

> -----Original Message-----
> From: William Tan [mailto:wil@dready.org] 
> Sent: Wednesday, September 21, 2005 1:35 AM
> To: Sakimura, Nat
> Cc: Drummond Reed; Chetan Sabnis; xri@lists.oasis-open.org
> Subject: Re: [xri] GCS Spoofing
> 
> I agree with Nat that it will definitely involve subjective judgment. 
> Not only that, newer versions of Unicode may include more 
> characters that resemble existing syntax characters, and we 
> have to clarify how the specifications relate to the version 
> of Unicode.
> 
> After collecting all the characters that may resemble the 
> syntax characters, it appears that most of the really obvious 
> ones are already taken care of by NFKC. For example, U+FE61 
> (SMALL ASTERISK) is mapped to the regular U+002A (ASTERISK). 
> The attached HTML highlights the NFKC-equivalent characters 
> in red. Firefox handles much more glyphs than Internet Explorer.
> 
> If someone tries to spoof an XRI authority by using one of 
> these look-alike characters in an email link, for example, 
> shouldn't the user agent convert the XRI reference to 
> XRI-normal form (which contains the NFKC step), thereby 
> mitigating the attack?
> 
> I've been very loose when collecting these characters (I used 
> a name-based search, which may not be extensive enough). Many 
> of the characters listed are not a problem, but some do raise 
> concerns. As Nat said, do we want to go down the slippery 
> slope of banning the characters at spec-level rather than 
> leaving as a recommendation to the client implementations?
> 
> wil.
> 
> 
> Sakimura, Nat wrote:
> > 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 
> >
> >
> >   
> 


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