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


Gabe,

Wil's suggestion is to do precisely what you suggest: simply fix the problem
in the scope of the XRI specifications, since we CAN'T fix it at the scope
of the IRI specifications.

This precisely parallels the conclusion we came to last week
(http://lists.oasis-open.org/archives/xri/200509/msg00045.html) about
requiring NFKC rather than NFC when encoding XRIs from "native" form into
XRI normal form. We can't fix the fact that IRI choose the looser NFC --
there were obviously good reasons they choose to do so, although they
recommend the stricter NFKC if it can be used. However since we don't have
the installed base, we can require NFKC for encoding of XRIs. This doesn't
hamper XRI-to-IRI compatability since all valid XRIs can still be converted
to valid IRIs.

Wil's suggestion proposes to the same thing for the iunreserved character
set -- allow a subset of what IRI allows in order to prevent semantic
attacks on XRI delimiter characters.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, September 19, 2005 10:57 AM
To: William Tan; Drummond Reed
Cc: Sakimura, Nat; Chetan Sabnis; xri@lists.oasis-open.org
Subject: RE: [xri] GCS Spoofing

Are we the right venue to propose solutions to problems that are greater
than XRI? If these are IRI problems, perhaps we should acknowledge this
issue and then defer to the folks working on IRI (e.g. IETF folks,
others) to deal with these spoofing issues more broadly. 

I think that any XRI-specific solution should only be XRI-specific to
the extent that an IRI-generic solution cannot address the solution.
That is, an XRI-specific solution should only address security issues
that are specific to XRI, rather than IRI in general.

	-Gbe

> -----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-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_workgr
> oups.php 
> 
> 



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