[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]