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

[John C Klensin <[e-mail]>]

--On Thursday, March 19, 2015 18:29 +0000 Shawn Steele
<[e-mail]> wrote:

>> Any of these forms, if they can be guaranteed to be stable,
>> will satisfy that condition, but the point about the
>> discussion is that identifiers that are "reasonably mnemonic"
>> as one could characterize IDNs, do occupy a space between
>> machine and human interaction with writing systems.
> 
> This discussion seems to be about lots of things, but
> "reasonably mnemonic" would limit the problem hugely.  That
> implies that I can see it and remember what it was to type it
> later.  However that scenario doesn't hit any of the security
> concerns being raised as I'm going to type it using the
> appropriate keyboard for my language.  Sure, if the domain had
> a Cyrillic l may have trouble, however that's not mnemonic,
> that's someone being sneaky.  (See fraud below)

Shawn, for better or worse, "reasonably mnemonic" might be an
attractive way to think about things, but it is never been a
requirement the community has chosen to impose on the DNS (even
though ICANN has chosen to impose variations on it on domains it
controls).  See RFC 2181 for some rather strong statements to
the contrary.   "No mnemonic requirement" is actually important
outside the IDN space because there are a number of applications
that use strings  as owner names that, on inspection, we might
guess were hashes.  Lack of willingness to impose such a
restriction is also the main reasons why IDNA has never
contained a "no mixed scripts" rule (there is also a technical
reason, but we could have gotten around that one).

>> Actually, Arabic even has potential "variants" among the
>> digits, so while you can make the identifier be based on the
>> numeric value of what the human wrote in whatever writing
>> system, you get into issues of recognition of identifiers
>> etc. once they are communicated in their human-readable form.
> 
> That's digressing from my point.  I was trying to say that, if
> we consider the problem without any human factors, we already
> have unique IDs. 

We also, as you point out, have no justification for IDNs.  The
community has, for better or worse, thoroughly rejected that
position, so I hope we can move on.

> There's no way that machines confuse any of
> these names, it's only the humans that do that.

Quite the contrary.  If differences among coding sequences for
the same string, depending on human-invisible distinctions such
as choice of IME or host, can produce different results and then
a comparison procedure is used, then, in practical terms, it is
the machines that are confused.  That is precisely why we
normalize before comparing and one of the key reasons why
IDNA2008 DISALLOWs a lot of code points that might be
problematic for machine comparison purposes.   By contrast,
case-folding and DISALLOWing some other characters are about the
potential for human confusion because machines know perfectly
well that upper and lower case characters (no matter how coded
as long as they are coded distinctly) are different.   Probably
part of the present problem is that we may need to be a little
more precise about those distinctions than we have been in the
past but, while that would change our vocabulary, it would not
change the problem.

Some of the above might help with fraud detection or prevention,
but the requirements exist without any consideration of fraud.

Please read and try to understand the distinction I tried to
make between coding artifacts and character confusion in my
previous response to you and try to work your way through the
discussion of cases in draft-klensin-idna-5892upd-unicode70-04
-- they really are important to this.

>...
> That's an additional requirement to the "reasonably mnemonic"
> above.  However if this entire exercise is intended to
> counteract fraud, then we get my view that "trying to address
> these codepoints is way more costly than its benefit".  

It is not entirely or even largely to counteract fraud.  Things
like ICANN's Label Generation Rules might well be defined in
terms of fraud or at least confusion.  I encourage you to read
about them and comment.  But, these particular issues, as
described in draft-sullivan-lucid-prob-stmt and
draft-klensin-idna-5892upd-unicode70 (-04 and anything later),
are really about resolving different coding for the same
character, and not confusion or fraud except incidentally.
There is a big issue in that about what "same character" means,
but that still isn't about fraud or even about confusion between
pairs of characters that almost everyone agrees are different.

> The people in this room aren't going to click on
> "1stbank.trustme.com", but everyone else on the planet (or at
> least 90% of them) click that link.  So worrying about someone
> spelling it "lstbank.com" provides close to zero value.  At
> least in the right font 50% of the other humans might start
> suspecting that one.

And that, while interesting, seems to me completely irrelevant
to the current discussion.   If you want to make comments on the
fraud case, please explain how the "humans in this room" are
expected to distinguish between "nür" (with the middle
character coded as U+00FC) and "nür" (with the middle character
coded as U+0075 U+0308).  Applying NFC to both strings handles
that case perfectly well and that is why we do it.  Part of the
issue here is the cases that NFC does not handle as well.

>...
> (This total obliviousness to security/spoofing/phishing isn't
> even limited to DNS, I've received calls because of billing
> glitches and the bank says "you can pay now, give us your CC
> or check routing info".  That's normal.  They they ask my
> secret code or whatever to verify it's me, and I point out
> that I can't even verify that they're who they say they are
> and they're stumped.  Well, you can call us back at
> 1-800-123-4567.  Seriously!?!?!  Even my bank has no clue what
> security is?)

Of course.  And I've had endless arguments with various
financial institutions, both about their procedures and their
barriers to letting me use even rudimentary self-protective
measures.  But it has nothing to do with the present question
whether or not I carry out my fantasy of posting all of those
examples to rants-are-us.example or, better yet, the more
elegant (or perverse, depending one one's perspective)
rants-я-us.example.

> Fix that, and then we can talk about whether it's worth fixing
> a couple esoteric code points.  There are FAR easier exploits
> for any serious attacker to attack.  It's certainly not worth
> risking breaking real strings and real mnemonics that real
> users might want to use.  (IMO its not even worth prohibiting
> I♥NY.com)

Sorry, but the community believes you are in the rough.
Incidentally, one of the main reasons why the second character
in I♥NY is DISALLOWED (and hence why the string is invalid as
a U-label) also has nothing to do with fraud but is associated
with difficulties in precise enough description of symbols in
screen readers and other text-to-speech applications that they
can be typed back in.  That is another human consideration of
course... too bad about those humans, the world would be so much
neater without them.

>...

I've probably said too much already -- please try to forgive my
frustration after struggling with the real for more months than
I want to think about and being regularly distracted by people
who want to talk about confusion.  Again, please read the two
I-Ds which, at least IMO, actually do give a decent description
of what the problem is thought to be or at least parts of that
puzzle.   IMO, if either uses words like "confusion" or "fraud",
they are historical errors grounded in ways of thinking about
other problems.  

If you want to talk about confusion and fraud, they are really
interesting discussions on which a lot of good people have spent
a lot of time, but they are really not what this is about.

 best,
    john