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

From: "Addison Phillips" <[email-masked]>
Date: Thu, 12 May 2005 11:42:52 -0700

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:[email-masked]]
> 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: [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]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: [email-masked]
> > [mailto:[email-masked]] 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: [email-masked]
> > [mailto:[email-masked]]
> > > 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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> >

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 May 2005 22:47:27 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "McDonald, Ira" <[email-masked]>; "Peter Constable" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Thursday, May 12, 2005 11:42 AM
> Subject: RE: [Ltru] [psg.com #967] address homographissuesinsecurityconsiderations
>

> Text would be *most* helpful.
...

In the interest of reaching closure on this item, as a technical contributor I'll
propose some words that I think will start to address some of Ira's concerns.

1) In section 6 (security considerations) the first paragraph would need to be
modified since there would no longer be just one issue.

2) Add the following paragraph to section 6:

The limited repertoire of characters permitted in language tags provides
few opportunities for homograph confusion.  Whether there are any at
all depends upon the font in use, but, for some widely used fonts,
confusion between "O" and "0", or "I", "l", and "1" need to be considered
as realistic possibilities.  The language tag reviewer SHOULD reject
registration requests for tags or subtags that could be confused in this
way  with existing ones.

Randy

---

From: John Cowan <[email-masked]>
Date: Sat, 21 May 2005 12:25:21 -0400

> registration requests for tags or subtags that could be confused in this

I think this is too strong because of the ell vs Eye contrast combined with
the official caselessness of tags.  We already have 23 pairs of subtags that
differ only in having an ell vs. an eye.  For example, ia and la are both
valid language subtags, as are sal and sai; GI and GL are both valid region
subtags.  In fact, ii, li, IL, and LI are all valid subtags.

As long as everything is cased consistently, there is no problem, but if someone
uses anomalous casing, these would become a problem under your proposal.
I propose therefore that only zero/oh, one/eye, and one/ell be treated as
confusables; these could arise only in variant subtags.

-- 
John Cowan  www.reutershealth.com  www.ccil.org/~cowan  [email-masked]
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
        --The Linux-nationale by Greg Baker