Re: [Idna-update] [Ext] Re: emoji and security

John C Klensin <john-ietf@jck.com> Sun, 18 March 2018 02:57 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: idna-update@ietfa.amsl.com
Delivered-To: idna-update@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B284126BF0 for <idna-update@ietfa.amsl.com>; Sat, 17 Mar 2018 19:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 1mZg3-T7Tqya for <idna-update@ietfa.amsl.com>; Sat, 17 Mar 2018 19:57:40 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CD71243F3 for <idna-update@ietf.org>; Sat, 17 Mar 2018 19:57:40 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1exOVr-0006if-7W; Sat, 17 Mar 2018 22:57:35 -0400
Date: Sat, 17 Mar 2018 22:57:27 -0400
From: John C Klensin <john-ietf@jck.com>
To: Kim Davies <kim.davies@iana.org>, Michel Suignard <michel@suignard.com>
cc: idna-update@ietf.org, Andrew Sullivan <ajs@anvilwalrusden.com>, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>
Message-ID: <7DEBC7AEB8C79C7B9A7ECAAF@PSB>
In-Reply-To: <20180314151515.GA70553@KIDA-6861.local>
References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <DM5PR1901MB219712F39A6297F9A147312DA2D30@DM5PR1901MB2197.namprd19.prod.outlook.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <DM5PR1901MB2197A704B3233E5236EB703AA2D20@DM5PR1901MB2197.namprd19.prod.outlook.com> <ac2e51de-a9ad-c8ee-96b0-5b50a0e225c4@ix.netcom.com> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <B365481D-F9B6-46AD-BC3A-CC98695131E2@frobbit.se> <DM5PR1901MB219746D7A8CC8E1699DDC773A2D10@DM5PR1901MB2197.namprd19.prod.outlook.com> <20180314151515.GA70553@KIDA-6861.local>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/idna-update/yhKvsjs2YxK536-lxIqgdG_pT0Q>
Subject: Re: [Idna-update] [Ext] Re: emoji and security
X-BeenThere: idna-update@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" <idna-update.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idna-update>, <mailto:idna-update-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idna-update/>
List-Post: <mailto:idna-update@ietf.org>
List-Help: <mailto:idna-update-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idna-update>, <mailto:idna-update-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2018 02:57:42 -0000

Kim,

Just to clarify one other part of your comments...

--On Wednesday, March 14, 2018 11:15 -0400 Kim Davies
<kim.davies@iana.org> wrote:

> However, given the IDNA tables are posted, some IDNA 2008
> implementations use them as a shortcut to greatly simplify
> their code. As a consequence, the landscape of implementations
> is likely variable because you have some implementations using
> the IANA-published tables limited to the Unicode 6.3
> repertoire, and others using more recent versions because they
> are deriving from Unicode properties directly.

yes.  But that is inevitable, whether there are tables stored at
IANA or not.   Unless every registry in the DNS (not just TLD or
SLD registries) is either calculating code point and label
validity using the IDNA rules in real time or making that
calculation every time a new version of Unicode is announced
(and exactly the same number of minutes after the announcement)
_and_ every instance of every lookup application does one of
those things as well, there will always be some practical risk
of unsynchronized implementations.  I don't know whether having
the tables posted by/at IANA makes that problem any worse, but
it seems obvious to me that it doesn't make it much worse.

Noting that the DNS itself uses a slow synchronization model,
those properties of IDNA2008 probably don't even change the
problem in a qualitative way.

best,
    john