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