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


Yes, I didn't mean to indicate I want a "point solution for a point problem"
either. And I'm very sure we're not going to solve these problems 100%.

And knowing what's involved, I'm reluctant to add a new GCS character too.
In fact, I took the time to check, and "~" is not an option, since it's not
a reserved char in IRI/URI (or XRI). The only xri-subdelims left that could
be elevated to GCS chars are ",", ";", "'", and "&". All are poor choices
IMHO.

I think you're right - client-side guidance may just be the best solution to
this particular attack.

Wil, since an IRI authority, to be resolved, would have to be either an IP
address or a DNS name, wouldn't it require an IDN string to produce one of
the characters use to spoof a GCS character? And what protections are
clients developing for these kinds of IDNs?

=Drummond 


-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Thursday, September 22, 2005 5:47 PM
To: Drummond Reed; William Tan
Cc: xri@lists.oasis-open.org
Subject: RE: [xri] GCS Spoofing

Well, for one, the first proposal makes the conversion to/from HTTP URIs
more complicated. Not a show stopper.

Secondly, do we have any more characters that can be GCS characters?
That could be a show stopper. 

Third, it seems like we are solving a point issue with a point solution
- this might be a proper way to address the problem, but it complicates
processing and doesn't address the broader homographic attack issues -
something I think Nat is correct in stating has to be handled by client
implementations... Ie the ability to indicate by color or other visual
cue where separators are, and quickly indicate whether an authority is a
IP/DNS name (IRI authority) or XRI authority... 

I'm not sure we're ever going to solve these problems 100%.

 -Gabe



> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Thursday, September 22, 2005 5:39 PM
> To: 'William Tan'
> Cc: xri@lists.oasis-open.org
> Subject: RE: [xri] GCS Spoofing
> 
> Wil,
> 
> First, thank you for thinking about this as deeply as you have. Both
> suggestions are good ones and made me seriously stop and 
> think about whether
> they could work.
> 
> The problem I see with the second one (requiring an IRI 
> authority to be a
> cross-reference), is that it breaks the ability for those 
> cross-references
> to serve as XRI authorities (which is proving to be a very 
> popular feature
> for peer-to-peer communities). So I think that one's out.
> 
> The primary downside I see to the first suggestion (assigning 
> a new GCS
> character to IRI authorities) is that it breaks symmetry with 
> URI/IRI syntax
> in this area.
> 
> However, it *might* be viable because it would still cleanly 
> separate into
> the GCS character for an IRI authority followed by the iauthority
> production. Essentially we'd just be "prefixing" all IRI 
> authorities with a
> GCS character. 
> 
> This is ringing a memory bell that this option came up once 
> before, last
> winter, to solve a different issue. As I remember, DaveM 
> argued against it
> for IRI/URI compatability reasons.
> 
> Dave, can you weigh in again about whether this would be viable?
> 
> =Drummond 
> 
> 
> -----Original Message-----
> From: William Tan [mailto:wil@dready.org] 
> Sent: Thursday, September 22, 2005 10:21 AM
> To: Drummond Reed
> Cc: xri@lists.oasis-open.org
> Subject: Re: [xri] GCS Spoofing
> 
> While I'd love to see a clean solution to this, I'm afraid there is 
> nothing we can do to cover all potential attack surfaces.
> 
> A crazy idea would be to denote an IRI authority with a 
> prefix character 
> (e.g. '~') or mandate that an IRI authority must be specified 
> as a cross 
> reference. In either cases, it narrows the set of characters 
> allowed to 
> begin the xri-hier-part production to a handful few.
> 
> I don't have enough experience with XRI and am sure that 
> there are many 
> pitfalls to this proposal so just fire away.
> 
> wil.
> 
> Drummond Reed wrote:
> > I agree that *at the very minimum* we should add coverage 
> of this topic to
> > the Security and Data Protection section of Syntax to address this
> specific
> > type of semantic attack. 
> >
> > Section 3.3 already addresses "Spoofing and Homographic 
> Attacks". I'd
> > suggest add an additional section called "XRI Authority 
> Spoofing Attacks"
> > that explains the attack Wil brought up (an IRI authority 
> spoofing an XRI
> > authority) and provides specific guidance to user agents.
> >
> > Wil, Nat, are you both in agreement that this is the only 
> practical option
> > we have at the XRI specification level? Or is there anything we can
> cleanly
> > specify that will help prevent XRI authority spoofing 
> attacks (or other
> > semantic attacks based on XRI delimiters)?
> >
> > =Drummond 
> >
> > -----Original Message-----
> > From: Wachob, Gabe [mailto:gwachob@visa.com] 
> > Sent: Tuesday, September 20, 2005 11:03 AM
> > To: William Tan; Sakimura, Nat
> > Cc: Drummond Reed; Chetan Sabnis; xri@lists.oasis-open.org
> > Subject: RE: [xri] GCS Spoofing
> >
> > I meant to say "note these issues in a security issues 
> section of the
> > Syntax document".  
> >
> >    -Gabe
> >
> >   
> >> -----Original Message-----
> >> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> >> Sent: Tuesday, September 20, 2005 10:59 AM
> >> To: William Tan; Sakimura, Nat
> >> Cc: Drummond Reed; Chetan Sabnis; xri@lists.oasis-open.org
> >> Subject: RE: [xri] GCS Spoofing
> >>
> >> Guys-
> >> 	I'm glad to see we're coming to consensus here. I'd entertain a
> >> separate effort to document best practices and security 
> >> issues with the
> >> XRI syntax, especially with regards to spoofing. I'd 
> guess, however,
> >> that this effort should wait until we have *some* significant
> >> deployment. Perhaps we just note these issues in the 
> syntax issues and
> >> defer more in-depth best practice recommendations until we 
> have more
> >> real world experience?
> >>
> >> 	-Gabe
> >>
> >>     
> >>> -----Original Message-----
> >>> From: William Tan [mailto:william.tan@neustar.biz] 
> >>> Sent: Tuesday, September 20, 2005 10:40 AM
> >>> To: Sakimura, Nat
> >>> Cc: Drummond Reed; Chetan Sabnis; xri@lists.oasis-open.org
> >>> Subject: Re: [xri] GCS Spoofing
> >>>
> >>> Hi Nat,
> >>>       
> >>>> 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. 
> >>>>   
> >>>>         
> >>> Ok, let's not go there. I was convinced long ago that we 
> can't ban 
> >>> characters, especially not when they're simply visually 
> >>>       
> >> similar, but 
> >>     
> >>> semantically very different.
> >>>       
> >>>> 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. 
> >>>>   
> >>>>         
> >>> I think that is a fairly interesting proposal. Also, we 
> may want to 
> >>> drive home the point that punctuations, spacing, symbols 
> >>>       
> >> (potentially 
> >>     
> >>> other categories) characters should be avoided when creating XRI 
> >>> authorities. Client application may want to warn the user 
> >>>       
> >> of any such 
> >>     
> >>> character classes that are not explicitly allowed as XRI syntax 
> >>> characters appearing in the authority segment.
> >>>
> >>> 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_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]