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

From: "Addison Phillips" <[email-masked]>
Date: Mon, 23 May 2005 15:03:28 -0700

Note that confusables cannot appear in the registry: registry entries are always lowercase excepting regions (uppercase) and scripts (titlecase). Scripts and ISO 3166 codes are both alpha-only (no digits!!)

Confusables can only affect language tags. These tags will not be well-formed excepting the use of 0/o and 1/l in primary language tags and variants.

So then... would this text work (in possibilities for registration section??):

<t>Language tags are formed from ASCII letters and digits. Some of these characters may be confused when displayed in certain fonts in certain user interfaces. In well-formed tags (where all of the subtags are actually valid), the only subtags that are affected are registered primary-language subtags (those longer than four characters, none of which exist at the time of adoption of this document) or variant subtags. The character pairs normally considered confusable in these subtags are 0 vs. O (%x30 vs. %x4F) and 1 and l (%x31 vs. %x6c). No subtags will be permitted for registration that differ only by these character pairs. For example, if a subtag 'example' (%x65.78.61.6d.70.6c.65) were registered as a variant, the subtag 'examp1e' (%x65.78.61.6d.70.31.65) would not be valid for registration. In addition, applications for registration that present obviously confusable sequences (such as 'examp1e') will probably be rejected.</t>

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?23? 14:20
> To: [email-masked]
> Subject: RE: [Ltru] [psg.com #967] address homograph issues
> insecurityconsiderations
> 
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of
> > John Cowan
> 
> 
> > 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.
> 
> As John notes, there isn't an issue for subtags from ISO source
> standards when casing conventions are applied, though there certainly
> could be when they are not -- e.g. "ia" and "la" in ISO 639-1 -- but we
> don't want to prohibit such on the basis of failure to apply casing
> conventions: a security-conscious app *should* apply the casing
> conventions if displaying these tags in a UI.
> 
> As John also notes, zero/Oh, one/Eye and one/el issues can arise for
> variants, and we should ensure that they are prevented. They can also
> arise for the registered-lang subtag, and that should also be prevented.
> 
> The registered-lang subtags is also susceptible to the el / "Eye" issue
> since there are no casing conventions for this subtag. I think we should
> be adding prevention for that as well.
> 
> Since extensions cannot be interpreted without reference to other RFCs,
> I don't think we need to worry about homographs within extensions.
> 
> 
> 
> 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

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 23 May 2005 15:25:27 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "Peter Constable" <[email-masked]>; <[email-masked]>
> Sent: Monday, May 23, 2005 3:03 PM
> Subject: RE: [Ltru] [psg.com #967] address homograph issuesinsecurityconsiderations
...
> So then... would this text work (in possibilities for registration section??):
...

This is stronger than what I had proposed, since it's effectively MUST rather
than SHOULD.  (Just an observation)

The "Security Considerations" section still needs to mention the issue,
even if only to say "Potential homograph issues are addressed in section foo".

Randy

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 24 May 2005 04:13:20 +0200

Addison,
in case my vacations are finished a few points.

1. I introduced the homograph issue. You discussed it at length, so I hoped 
you would understand as you did for the dated entries... The homograph 
problem I rose is not about the registry but about the script/charset 
conflicts and/or script variations. Your system does not introduce/document 
any protection against homograph issues, while users would legitimately 
believe they are protected.

2. ditto about security and "nationality" disclosure. I do not want Randy 
to ban me again for defending Human Rights., so, I prepared and circulate a 
short declaration on lingual rights respect by standard makers. This kind 
of text needs to be reviewed by many for moral and ethical endorsement. It 
will propose it to  IETF as to everyone else. If IETF chooses to oppose it, 
your concept could continue. If IETF chooses to support it, it will 
probably call for a complete review. I told the problem enough ... I try to 
speed things. My target date is July 1st, Paris meeting with everyone 
there. I will obviously copy it to you as soon as I can.

3. My printer is down. I spent more than three dollars today to get your 
.02.txt version printed. Then I stared reviewing it. Now, you announce 
version 03.txt. I cannot follow: I will make a final review and publish it 
during the Last Call. Like Randy did: one mail per remark. Trying to reach 
consensus by exhaustion has also draught back. I only hope that 04.txt 
includes a global change and addresses the numerous remarks I made.

 From trying to make a summary today, just a suggestion.I disagree with the 
document and do not speak English, so I would be a poor contributor: I know 
you live with this text for one year; but you could try to think as a 
developer reading the current text for the first time. May be it could help 
your text to be easier to read and understand?
Cheers.
jfc

On 00:03 24/05/2005, Addison Phillips said:
>Note that confusables cannot appear in the registry: registry entries are 
>always lowercase excepting regions (uppercase) and scripts (titlecase). 
>Scripts and ISO 3166 codes are both alpha-only (no digits!!)
>
>Confusables can only affect language tags. These tags will not be 
>well-formed excepting the use of 0/o and 1/l in primary language tags and 
>variants.
>
><t>Language tags are formed from ASCII letters and digits. Some of these 
>characters may be confused when displayed in certain fonts in certain user 
>interfaces. In well-formed tags (where all of the subtags are actually 
>valid), the only subtags that are affected are registered primary-language 
>subtags (those longer than four characters, none of which exist at the 
>time of adoption of this document) or variant subtags. The character pairs 
>normally considered confusable in these subtags are 0 vs. O (%x30 vs. 
>%x4F) and 1 and l (%x31 vs. %x6c). No subtags will be permitted for 
>registration that differ only by these character pairs. For example, if a 
>subtag 'example' (%x65.78.61.6d.70.6c.65) were registered as a variant, 
>the subtag 'examp1e' (%x65.78.61.6d.70.31.65) would not be valid for 
>registration. In addition, applications for registration that present 
>obviously confusable sequences (such as 'examp1e') will probably be 
>rejected.</t>
>
>Addison
>
>Addison P. Phillips

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 23 May 2005 20:41:02 -0700

Hi -

> From: "JFC (Jefsey) Morfin" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, May 23, 2005 7:13 PM
...
> believe they are protected.

The language tag associated with a particular bit of content is of no consequence
whatsoever in determining whether that content might contain possible homographs.
The fact that a text is tagged as being in one language provides no assurance
whatsoever that it doesn't contain characters from scripts other than the one(s)
associated with that language.

Would it satisfy you if we were to include this statement in the security considerations
section?  Would other WG members object to including this statement?

> 2. ditto about security and "nationality" disclosure. I do not want Randy

What do you mean by "ditto"?  Please provide text if you want anyone to
pay attention to you.

> to ban me again for defending Human Rights., so, I prepared and circulate a

Misrepresenting the chairs' motives could be considered disruptive, and cause
for revocation of posting privileges.  You have been warned.

> there. I will obviously copy it to you as soon as I can.

Note that the WG last call for the registry i-d is planned for May, 2005.
Unless something catastrophic happens, we should have been able
to hand it to the IESG for consideration for publication by sometime
in June.

> includes a global change and addresses the numerous remarks I made.

NOTE WELL:
If you hope to influence the WG, it would be better to make your comments
sooner, rather than waiting for WG last call.  Issues that have been
resolved or rejected prior to WG last call will NOT be re-opened during
last call unless there is a clear explanation of why the WG decision was
technically incorrect.

>  From trying to make a summary today, just a suggestion.I disagree with the

Broad statements like this are not helpful.

> your text to be easier to read and understand?

This is sound advice for anyone writing an i-d, but it has limits.  For example,
we can't reasonably expect to produce a technical specification that would
be readily understood by someone not proficient in the language of that text.
Still, it is good to keep the first-time reader in mind, and to strive for clarity
at all times.

...

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 24 May 2005 10:38:45 +0200

Randy Presuhn wrote:

> Would other WG members object to including this statement?

No, it's a good idea, better than the rules trying to enforce
a minimum of common sense on the side of the tag reviewer.

| A language tag in content is only a claim by the publisher of
| this content, it can be intentionally misleading.  E.g. the
| script could be abused to diguise homographs attacks.

Something in this direction in the security considerations.

                            Bye, Frank