Re: [Lucid] FW: [mark@macchiato.com: Re: Non-normalizable diacritics - new property]

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 19 March 2015 19:32 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: lucid@ietfa.amsl.com
Delivered-To: lucid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629631A3B9B for <lucid@ietfa.amsl.com>; Thu, 19 Mar 2015 12:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txdUl03O-h7R for <lucid@ietfa.amsl.com>; Thu, 19 Mar 2015 12:32:08 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3A81A8868 for <lucid@ietf.org>; Thu, 19 Mar 2015 12:32:01 -0700 (PDT)
Received: from mx1.yitter.info (unknown [67.211.120.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AF6AE8A031 for <lucid@ietf.org>; Thu, 19 Mar 2015 19:32:00 +0000 (UTC)
Date: Thu, 19 Mar 2015 15:31:59 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: lucid@ietf.org
Message-ID: <20150319193158.GH6655@mx1.yitter.info>
References: <CY1PR0301MB07310C68F6CFDD46AE22086F82190@CY1PR0301MB0731.namprd03.prod.outlook.com> <20150311200941.GV15037@mx1.yitter.info> <CY1PR0301MB0731F4EBE5EB5C3340F7059282190@CY1PR0301MB0731.namprd03.prod.outlook.com> <20150319014018.GI5743@mx1.yitter.info> <BLUPR03MB1378184CE32E928A3086665582010@BLUPR03MB1378.namprd03.prod.outlook.com> <20150319023029.GA6046@mx1.yitter.info> <BLUPR03MB137886903F15000BB01E3F5882010@BLUPR03MB1378.namprd03.prod.outlook.com> <A62526FD387D08270363E96E@JcK-HP8200.jck.com> <550B0A32.8080704@ix.netcom.com> <BLUPR03MB1378985F9780A98646E7B31B82010@BLUPR03MB1378.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB1378985F9780A98646E7B31B82010@BLUPR03MB1378.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lucid/ywS_B9Zl8fQFCpdy69Klw01Hy4M>
Subject: Re: [Lucid] FW: [mark@macchiato.com: Re: Non-normalizable diacritics - new property]
X-BeenThere: lucid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Locale-free UniCode Identifiers \(LUCID\)" <lucid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lucid>, <mailto:lucid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lucid/>
List-Post: <mailto:lucid@ietf.org>
List-Help: <mailto:lucid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lucid>, <mailto:lucid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 19:32:09 -0000

On Thu, Mar 19, 2015 at 06:29:06PM +0000, Shawn Steele wrote:

> 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.

No, because it's reasonably mnemonic _for someone_, not for everyone.
You're assuming that localization is the only relevant parameter, but
it's not: the problem with identifiers for Internet-wide use is that
they're supposed to be both internationalized and localized at the
same time. 

For instance, CAs are supposed to be doing validation on these names
and nailing them to organizations.  We've already had problems with
invalid issuance of certificates (as you may be aware, since your
apparent employer has been one of the targets), and this issue opens
that door more widely.  CAs are not going to be experts in every
writing system, and the same-script registration rules won't help
anything here because they're ineffective.

Similar issues might be expected for other kinds of identifiers in
Internet-scope use.

I think if you read the I-D carefully, you'll discover that this point
is made in section 3.1.

> 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.

And as I said before, this is tautologically true or false, depending
on what you mean by "ID".  It seems you're devoted to "tautologically
true", but I fail to understand why you think that's a remotely
interesting point in this discussion.  Everyone already agrees that
there's a human factors issue here.

> 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.

"There is that problem over there, so this problem isn't worth
fixing."  I'm not suggesting that the other problem is not an issue,
but this one turns out to be an in-principle misunderstanding on the
part of the IETF about how it was going to construct internationalized
identifiers.  In principle misunderstandings are the sort of things
that one must address (even to conclude "not worth fixing") if one is
going to write protocols that are worth anything at all.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com