[Lucid] FW: [[e-mail]: Re: Non-normalizable diacritics - new property]

[Shawn Steele <[e-mail]>]

Oops, I seem to have dropped the list.

From: Shawn Steele
Sent: wenSjaj, march 11, DIS 2015 tera' 14:23
To: 'Andrew Sullivan'
Subject: RE: [Lucid] [[e-mail]: Re: Non-normalizable diacritics - new property]


>       Any character that can be confused for

>   another one can be called confusable, and confusability can be

>   thought of as a spectrum with "visually similar" at one end, and

>   "homoglyphs" at the other.  (We use the term "homoglyph" strictly:

>   code points that normally use the same glyph when rendered.)



It says "there's a spectrum", but then "We use the term "homoglyph" strictly:..."  That seems like an attempt at a hard line, though it does say "normally"



> ʻokina



Hmm, I'd thought I'd seen it different, but maybe not, sorry if that was a bad example.  Actually, Wikipedia has a couple examples… http://en.wikipedia.org/wiki/%CA%BBOkina That’s part of my concern with saying “normally rendered the same”.  They don’t have to be, that’s the art of creating a font.



> I think we're all aware that you can't tell developers what font to use,

> but there is clearly an in-principle difference between "could be

> mitigated with font" and "cannot possibly be mitigated with font".



I suppose some characters are less likely to be able to be mitigated with a font, however I'm not sure I could easily find a font that mitigated a large set of characters.  I could perhaps suggest that font designers consider these things when adding characters or making a new font, but (as my okina choice demonstrates) I'm not sure which font(s) have what behavior.



Although I think it's fair for an RFC to indicate that some fonts can exacerbate the problem, I'm not sure that it's fair to state that parts of the problem could be "solved" by a font.  For example, sometimes the font choice may be under the control of the attacker.



> > Additionally it continues to treat these newly noticed characters as a

> > special case without considering the many existing problems.



> Where, please?



?? 2.2.2 explicitly emphasizes the Arabic Hamza Above case, though it does go on to mention that there are other characters.  However there are many confusable characters in IDNA.  Worse than just confusable glyphs perhaps are confusable concepts, as the discussion of "pronunciation" alludes.  'okina isn't confusable if you pronounce it 'okina and pronounce the quote as a left quote.  Yet it is visually confusable.



For example, this focuses on the examples illuminated by a very esoteric Arabic code point.  I’m digressing, but I never see any discussion of 拔 vs 拨 or  暖 vs 暧 (depending on font, YMMV).  However those can be very confusable to Chinese readers, particularly if the context leads one to expect one character or the other.



> IDNA is supposed to be providing unique identifiers.  It in fact does, in the

> sense that when a series of U-labels or A-labels are put together they (respectively)

> produce exactly one FQDN that can be looked up.  That's why it's part of the problem.



At what level?  Sure, they’re unique as a binary number sequence.  But clearly they aren’t visually (or even audibly) unique, UTS#46 was created for that.  Nor are they linguistically unique as any of the numerous …nyms could cause confusion.  Nor are they a unique resource identifier as multiple names could actually point to the same place.



Can they provide a unique FQDN that maps to a single server?  Sure, but they could do that if we’d just left it at “all of Unicode”.



At the machine level, yes, IDNA provides unique identifiers.



At the human level, it most certainly does not.  For it to be unique at a human level would mean that I’d have to be able to hand a written note to another human and they’d be able to key that in with 100% accuracy.  This document notes the problems with l and 1, and obviously 0 and O, let alone any number of other problems.



I created http://L3-G0.com  However despite that, my mnemonic has led me to type l3-go on more than one occasion.  It’s also led me to tell the name to others whom I’m fairly sure have then miskeyed it.



Despite all that, I believe that IDN suffices for the purposes of allowing users to find web servers & machines that they are interested in.



However IDN does not suffice to provide an unambiguous (to humans) identifier.  Addressing the class of characters being discussed hear provides no statistically meaningful reduction of the potential ambiguity of IDN, particularly by a malicious attacker.  It also provides no statistically interesting improvement in the ability for well-intentioned users to find the resource they’re looking for, as presumably the users interested in the variations discussed here will be fully capable of using the correct variation.



So I don’t know what our goals are here.  I can envision several possibilities:



A)     A machine identifier suitable for uniquely identifying resources.

a.      IMO, this is already solved.  No machine is going to confuse any of these, they’re just numbers.

b.      Alternatively machines could use actual numbers (or GUIDs, or a specific bit of ASCII, or any other of a number of ways of generating true unique identifiers).

B)     We want a human safe unique identifier.

a.      The problem described here has no meaningful impact on the scope of the problem.

b.      I’m not sure this is achievable.  It’ll be hard for sure.

c.      IMO such an identifier could not also be perfectly linguistic.

                                                    i.     We’d have to map things that could be confused together in a way that would ensure there was no ambiguity in the resulting identifier.

                                                   ii.     Eg: map Latin, Greek & Cyrillic as appropriate.

                                                  iii.     Clearly such an ID couldn’t round trip to a “pretty” human form.  Though we could ensure a pretty human form always mapped to the same ID

d.      This isn’t IDNA

C)     We want to provide “safe” browsing using IDNA.

a.      Again, the issues being discussed here have no meaningful impact on the scope of this problem

b.      That would need to consider some of the far grayer areas than are being discussed here.

c.      I think other technologies are appropriate here, eg: spam filters, blacklists, safety plugins, certificates, etc.



Clearly some people think that the class of the problem here is a real problem, and presumably that it is worth the effort to attempt to solve the perceived problem.  In other words, that solving this would provide some statistical and measurable improvement in the security of IDNA.  However, I’m not able to follow the logic.



Perhaps if the document could provide some sort of statement of the reduction of confusable characters that would help.  Eg:  “Addressing this issue will reduce 90% of the confusion of IDN labels”.



-Shawn