RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations

["Addison Phillips" <addison.phillips at quest.com>]

Text would be *most* helpful.

I don't believe you were ignored previously. Quite the contrary, I'm interested in seeing closure, which means consensus, which means not ignoring comments. 

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> Sent: 2005?5?12? 11:38
> To: Addison Phillips; Peter Constable; LTRU Working Group
> Subject: RE: [Ltru] [psg.com #967] address homograph
> issuesinsecurityconsiderations
> 
> Hi,
> 
> Denial of Service (DoS) through masking of content by homograph language
> tags
> (e.g., in an LDAP directory of users) is a security risk that's supposed
> to
> be addressed in a 'Security Considerations' section (see section 2.3.3 and
> 4.6
> of RFC 3552 "Guidelines for Writing RFC Text on Security Considerations").
> 
> And saying that end users don't enter or view language tags is not
> sufficient.
> Content authors, content distributors, administrators and others generally
> _do_ have to enter or view language tags.
> 
> Since the roles of individuals who enter or view language tags were not
> defined in RFC 3066 (or in this latest replacement draft), the risks that
> may be associated with using language tags are ambiguous.
> 
> Although I was shouted down, I still dislike the use of RFC 2119
> requirements
> capitalized verbs in imperative statements with only implicit subjects,
> e.g.,
> "you the reader", whatever that means...
> 
> If I get some time soon, I'll write up some suggested text describing the
> roles of language tag users and recasting some of the conformance
> requirements
> (e.g., around the Suppress-Script field) in those terms.  Then I can be
> ignored again, but it will be recorded in the archives of this mailing
> list.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald at sharplabs.com
> 
> > -----Original Message-----
> > From: ltru-bounces at lists.ietf.org
> > [mailto:ltru-bounces at lists.ietf.org]On
> > Behalf Of Addison Phillips
> > Sent: Thursday, May 12, 2005 12:15 PM
> > To: Peter Constable; LTRU Working Group
> > Subject: RE: [Ltru] [psg.com #967] address homograph
> > issuesinsecurityconsiderations
> >
> >
> > Yes, but the security impact of such confusion is very small:
> > you get a match or not on some requested content. Or you get
> > the wrong content. But language tags are not addresses.
> > Addresses present a security risk. Asking for de-L996 is a
> > security risk how?
> >
> > Addison
> >
> > Addison P. Phillips
> > Globalization Architect, Quest Software
> > Chair, W3C Internationalization Core Working Group
> >
> > Internationalization is not a feature.
> > It is an architecture.
> >
> > > -----Original Message-----
> > > From: ltru-bounces at lists.ietf.org
> > [mailto:ltru-bounces at lists.ietf.org] On
> > > Behalf Of Peter Constable
> > > Sent: 2005?5?12? 8:46
> > > To: LTRU Working Group
> > > Subject: RE: [Ltru] [psg.com #967] address homograph
> > > issuesinsecurityconsiderations
> > >
> > > > From: ltru-bounces at lists.ietf.org
> > [mailto:ltru-bounces at lists.ietf.org]
> > > On
> > > > Behalf Of Addison Phillips
> > >
> > >
> > > > Close to rejecting it? It's utterly confused. Langtags
> > have nothing to
> > > do
> > > > with IDN (which uses xn-- for something special) and there are no
> > > > homographs in the ASCII range allowed for language tags
> > (unless you
> > > count
> > > > L vs. 1 and o vs. 0). But these are restricted in use
> > (nearly all the
> > > > defined tags use alpha codes) and would have no
> > measurable security
> > > impact.
> > >
> > > Quite so. To compare with the security issues of IDN is more than a
> > > stretch.
> > >
> > > On the other hand, can we be certain that someone someday
> > might not find
> > > a way to turn a confusion between e.g. 1996 and l996 in some future
> > > client protocol?
> > >
> > > I'm not saying I'm convinced it's something we need to do.
> > Just raising
> > > possibilities.
> > >
> > >
> > >
> > > Peter Constable
> > >
> > > _______________________________________________
> > > Ltru mailing list
> > > Ltru at lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru at lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> >


_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru