[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.