From nobody Tue Apr 11 11:59:28 2017 Return-Path: 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 16FBC12EC64 for ; Tue, 11 Apr 2017 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 l-PA7fRSsHgv for ; Tue, 11 Apr 2017 11:59:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3348112EC75 for ; Tue, 11 Apr 2017 11:59:11 -0700 (PDT) Received: by mork.alvestrand.no (Postfix) id B42487C006D; Tue, 11 Apr 2017 20:59:09 +0200 (CEST) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A31467C0067 for ; Tue, 11 Apr 2017 20:59:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfKnbKcytnIQ for ; Tue, 11 Apr 2017 20:59:09 +0200 (CEST) Received: from [192.168.8.107] (123-183-11.connect.netcom.no [176.11.183.123]) by mork.alvestrand.no (Postfix) with ESMTPSA id EAA987C0056 for ; Tue, 11 Apr 2017 20:59:08 +0200 (CEST) To: "idna-update@alvestrand.no" From: Harald Alvestrand Message-ID: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> Date: Tue, 11 Apr 2017 20:59:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:59:27 -0000 If you get both the first and the second message, everything should be OK. So long, and thanks for all the fish! Harald -- Surveillance is pervasive. Go Dark. From nobody Tue Apr 11 12:20:26 2017 Return-Path: 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 36F6712EC99 for ; Tue, 11 Apr 2017 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 NuQ_f_XDa0mK for ; Tue, 11 Apr 2017 12:20:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B5512EC98 for ; Tue, 11 Apr 2017 12:20:23 -0700 (PDT) Received: by mork.alvestrand.no (Postfix) id 73FB87C0074; Tue, 11 Apr 2017 21:20:21 +0200 (CEST) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 60A857C006D; Tue, 11 Apr 2017 21:20:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeTgIALm0xSm; Tue, 11 Apr 2017 21:20:20 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received-SPF: None (no SPF record) identity=mailfrom; client-ip=70.88.254.51; helo=bsa2.jck.com; envelope-from=klensin@jck.com; receiver=harald@alvestrand.no X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mork.alvestrand.no (Postfix) with ESMTPS id 3952F7C0056; Tue, 11 Apr 2017 21:20:20 +0200 (CEST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cy1Ks-0009LT-F7; Tue, 11 Apr 2017 15:20:18 -0400 Date: Tue, 11 Apr 2017 15:20:12 -0400 From: John C Klensin To: Harald Alvestrand , idna-update@alvestrand.no Message-ID: <0E35F143A8387E04EFEC4289@PSB> In-Reply-To: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> References: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> 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.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:20:24 -0000 Harald, Both test messages received here. Thanks for your, and the secretariat's, efforts in this (and for getting the messages out before I did -- bad week last week and it fell through the cracks). Enjoy your break and the presumed fish. john --On Tuesday, April 11, 2017 20:59 +0200 Harald Alvestrand wrote: > If you get both the first and the second message, everything > should be OK. > > So long, and thanks for all the fish! > From nobody Tue Apr 11 13:23:28 2017 Return-Path: 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 2ECED129ACD for ; Tue, 11 Apr 2017 13:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com 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 4CO9U-Pr0fqD for ; Tue, 11 Apr 2017 13:23:24 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621D11295A0 for ; Tue, 11 Apr 2017 13:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1491942204; bh=//A8GerQdpdGn3de4+3dzML18nombkE9HkaX yNtzFyw=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=E/ht88dHn4+Yj8lbsPwSmct2FhqKd6ryASk4DpXe/CTj78 PKMirTppisTYfiwmzZClbSyDFcJmcWe8mO1DdNrW7CjzDEnqrSqboxZsCy1+zIo9rKE C98lM2HOPbC4XO3EQasS/HwKU7l1QAe9ya5oTPG7xLmEes6gjnggpxbRDJ59foUdDG6 qy4Uuyf9mi9IVVat+v3d9f/RzBLQca1afFDBWuirvcpmlO06mOtWkWMGEp7LBt9hqvl dKvQLiUvXD14ymXO+cRY1O1Bk/FUOPh0nCRbzSJHKOZ/rEAbORKWkF/WNd7BLPfnfgJ znCDZfrZLw8sfq/FGJrbLacSXnKA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=kpFWwjgdlGjDYzDC7JwTB0I2krY4xpGBoYAKwB0V3oHbPmt6ngGKO+8mij9cff6oTM7QAUr86EJaismL6khTdA2D3aHZAT0IFBj01hCxi6vestigQv3znx6hAgRpzEUysRch2hhReIlZVoXVG1f7uxreSn5V7mO0wWssstCQ8MJXV9DT/YB9NyxgLTIQTPnb16wu+tgZK+jF3xABDFJRMwpAx+SIl58CgznP/QjHXWX+pJQRRDWpVmWlLJrhRGhVzLVfIgIKLxkK31oyvC1aoDJQIBHzk2mRST1vUCCbVLlOW2P3lsvIZ2Csx0Hy2MqAMlDcXgj05eRYThgiLoa+Tw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [71.19.252.32] (helo=[10.4.13.161]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cy2Ju-0007Wc-4n for idna-update@ietf.org; Tue, 11 Apr 2017 16:23:22 -0400 To: idna-update@ietf.org References: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> From: Asmus Freytag Message-ID: Date: Tue, 11 Apr 2017 13:23:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> Content-Type: multipart/alternative; boundary="------------6921990D0E7957B354921C40" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2545e64a33c2ff5d0c8247e3f65879986af044139f5da3574350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.19.252.32 Archived-At: Subject: Re: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:23:26 -0000 This is a multi-part message in MIME format. --------------6921990D0E7957B354921C40 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/11/2017 11:59 AM, Harald Alvestrand wrote: > If you get both the first and the second message, everything should be OK. > > So long, and thanks for all the fish! > > > Harald > > Confirming that both messages were received. A./ --------------6921990D0E7957B354921C40 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 4/11/2017 11:59 AM, Harald Alvestrand wrote:
If you get both the first and the second message, everything should be OK.

So long, and thanks for all the fish!


Harald

Confirming that both messages were received.

A./

--------------6921990D0E7957B354921C40-- From nobody Tue Apr 11 13:36:36 2017 Return-Path: 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 102E51274D2 for ; Tue, 11 Apr 2017 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tzAflbo-aqZi for ; Tue, 11 Apr 2017 13:36:32 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BFA129ADA for ; Tue, 11 Apr 2017 13:36:32 -0700 (PDT) Received: by mork.alvestrand.no (Postfix) id 88EF87C00BD; Tue, 11 Apr 2017 22:36:30 +0200 (CEST) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7928A7C006D; Tue, 11 Apr 2017 22:36:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3nxsTx9dG9E; Tue, 11 Apr 2017 22:36:29 +0200 (CEST) X-Greylist: delayed 00:06:28 by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4010:c07::22c; helo=mail-lf0-x22c.google.com; envelope-from=joseph.yee@gmail.com; receiver=harald@alvestrand.no X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) by mork.alvestrand.no (Postfix) with ESMTPS id F18BF7C0067; Tue, 11 Apr 2017 22:36:28 +0200 (CEST) Received: by mail-lf0-x22c.google.com with SMTP id s141so4445594lfe.3; Tue, 11 Apr 2017 13:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QXEx9LLz1USDTAJH3+OvavtmB4yfSppKm0YotCWw3II=; b=cs5tRiv4SL6IQBkUkQsbCw8YJ4jsHwDqnpLzIQWpIwdGMVKF/XBMswj4kqcQ9Rxc+c RTeTBm+qtUqlpmxvkfJ3btbIofzY17yfS/n3LMle0lIfssNxwtgbPopqrjyYQVDGIf7u OTBkVgRlwMpUVYNEtsU1LdXd7G7twSUJ7eLN3w1bYqFvDEBWiyxhidg0u9b/s6RrhWw9 ojkZ+OCGJi71HSmoAoHKBjlKe4FjyUmgCnqOvrjc/vHOrQHxohsEsVk5fIKv0Q4JlC5m Lo9wsRysZGXsyToZr6F0fYJ5z3DwS4c5W0sPGqmETIgcpFBKknCBnbTU2XrZwbBgr2W8 IKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QXEx9LLz1USDTAJH3+OvavtmB4yfSppKm0YotCWw3II=; b=t1f4tSJwUKp+qzrcBHWEUCC/MUaOwpUjmiD/UurqHUjivthivveNu2YPdAu1JWkJWB h1A+5bx6SfnqemiUCEeeeCN8QBuqCfGGxzQZnRA7uvhcZ0Lr/s1kqzozRTllFZ/eMt08 0isG0tgHNVuOa/84IrPmxsDRvjTggNM2xUfvZmXcA+AHbJfRmuUNgY8k9PBZy1AMWnPs YQWL8XnCjHbAggW8ECXjEQK2MKbVt7z3JAvntoNzzSGdgq6Fb8ZRmpSM5ndckIi0IwdP dEcfufgzIKFLcC3P6SQt0wlh8rhWyX+f0L+iNz1NKPFEXHDZFcQHufFToDMBv6IxcdnN 1Xsw== X-Gm-Message-State: AFeK/H1rHgmZKDJL0a5IzsqZHlXeHihtu0BAkxhJrfVVNa1tRCbC/4oLccOF0GLv+ILEfDCocusBNYVHteYKpQ== X-Received: by 10.25.28.137 with SMTP id c131mr21875736lfc.109.1491942599576; Tue, 11 Apr 2017 13:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.5.210 with HTTP; Tue, 11 Apr 2017 13:29:58 -0700 (PDT) In-Reply-To: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> References: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> From: Joseph Yee Date: Tue, 11 Apr 2017 16:29:58 -0400 Message-ID: To: Harald Alvestrand Cc: "idna-update@alvestrand.no" Content-Type: multipart/alternative; boundary=001a114012aaac5f9f054ce9f464 Archived-At: Subject: Re: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:36:34 -0000 --001a114012aaac5f9f054ce9f464 Content-Type: text/plain; charset=UTF-8 Received both, thanks. -Joseph On Tue, Apr 11, 2017 at 2:59 PM, Harald Alvestrand wrote: > If you get both the first and the second message, everything should be OK. > > So long, and thanks for all the fish! > > > Harald > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > --001a114012aaac5f9f054ce9f464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Received both, thanks.

-Joseph

On Tue, Apr 11= , 2017 at 2:59 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
If you get both the first and t= he second message, everything should be OK.

So long, and thanks for all the fish!


Harald


--
Surveillance is pervasive. Go Dark.

_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-upd= ate

--001a114012aaac5f9f054ce9f464-- From nobody Tue Apr 11 13:44:42 2017 Return-Path: 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 64713129AC5 for ; Tue, 11 Apr 2017 13:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IyIUBau2-aB0 for ; Tue, 11 Apr 2017 13:44:38 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366C3129AC6 for ; Tue, 11 Apr 2017 13:44:37 -0700 (PDT) Received: by mork.alvestrand.no (Postfix) id AB59D7C00BD; Tue, 11 Apr 2017 22:44:35 +0200 (CEST) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9D3357C0067; Tue, 11 Apr 2017 22:44:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLfiqBeWGcta; Tue, 11 Apr 2017 22:44:34 +0200 (CEST) X-Greylist: delayed 00:06:28 by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4002:c09::236; helo=mail-yb0-x236.google.com; envelope-from=markus.icu@gmail.com; receiver=harald@alvestrand.no X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) by mork.alvestrand.no (Postfix) with ESMTPS id C65E07C006D; Tue, 11 Apr 2017 22:44:33 +0200 (CEST) Received: by mail-yb0-x236.google.com with SMTP id m133so2294885ybb.1; Tue, 11 Apr 2017 13:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zg4qcM1LA0UyrSwxxCcXVSCFxnp3fS1lPx+XV/7BkEY=; b=Tfvw7cgDg2hdInHr+2czzoHzfKx+LgqxOhPzFQ6GKF84R8X5RG5uh8X+ciSaVChpQs VlwwvuSuP4YzCnIQUXg3TsnrypDNtHKpGL2f/Nkt7bSJHGAX2jqtQ/Rgl+AZc2up27+o jIYLM+XrpvSUIxXOYLQjCKeAGNHmNz3qHwijYlunwOfBuFv0dVstDnDJhP4FY6FTNhuK aXq0kZ9qmnng+4tjt2aMirxFWWK/aQ/vKnrHMe1HOT5OoI3thbHxCo6TQAZio+mrgr4p uWdM/Kn6ErwEzI869B0VICemmXVp9FQaH7lMs2zuHIwAuMJyqwQt+E86IHm+tzdaw8FN z/9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zg4qcM1LA0UyrSwxxCcXVSCFxnp3fS1lPx+XV/7BkEY=; b=MER1PY1FKYMZJ/YsUfWc67RKKc4qx9KQIcL3R6LLhvHcph1RUl/3TMQB8rdbNqSJ0X M/kXGH6SDoNEPtLqJVbzaoblSbgI0pc4OBKMtHfIURODgXnYKvCfS7EtvnQH2BYSyzf4 570HwCELCaDXrv2YQuskrd+Xlg8s/sWJq+PG+q2QmYigw5OH9CvwmVGuwnuv7p+N+AwL /ivLpYpVSuawaeT0Y0AG/6lBDkjIHUk0nEQ2P8ZWuXGB01mGbK56/+B/jg524fjspMzd 8ahG39wbPAaTaUWPeUOQaMnkoiKd05fWTF/K27bgjfAwNAwmQA+DVlqfC6f4ZqJHTmG+ 9e0A== X-Gm-Message-State: AN3rC/5t7BHxoJl74sUhHcLeXtZGfHhSK9yyvq40plAyLsW/4ZSMwy6Ng69xX7hvyLA7TKQAnHaikXkAjk9Plg== X-Received: by 10.37.172.229 with SMTP id x37mr9046568ybd.86.1491943084159; Tue, 11 Apr 2017 13:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.176.9 with HTTP; Tue, 11 Apr 2017 13:38:03 -0700 (PDT) In-Reply-To: References: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> From: Markus Scherer Date: Tue, 11 Apr 2017 13:38:03 -0700 Message-ID: To: Joseph Yee Cc: Harald Alvestrand , "idna-update@alvestrand.no" Content-Type: multipart/alternative; boundary=f403045eb1a28e8291054cea11b8 Archived-At: Subject: Re: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 20:44:39 -0000 --f403045eb1a28e8291054cea11b8 Content-Type: text/plain; charset=UTF-8 I don't seem to have a message that says "first of two messages". Is that bad? markus --f403045eb1a28e8291054cea11b8 Content-Type: text/html; charset=UTF-8
I don't seem to have a message that says "first of two messages". Is that bad?
markus
--f403045eb1a28e8291054cea11b8-- From nobody Tue Apr 11 14:00:52 2017 Return-Path: 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 CD583127601 for ; Tue, 11 Apr 2017 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 ZMXBAakPjVXW for ; Tue, 11 Apr 2017 14:00:48 -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 ADF70126D73 for ; Tue, 11 Apr 2017 14:00:48 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cy2u4-0009dc-Jg; Tue, 11 Apr 2017 17:00:44 -0400 Date: Tue, 11 Apr 2017 17:00:39 -0400 From: John C Klensin To: Markus Scherer cc: Harald Alvestrand , idna-update@ietf.org Message-ID: <3963BC66D01F8CD9F6C8BB7D@PSB> In-Reply-To: References: <61086822-db76-0568-334e-18a5405d3693@alvestrand.no> 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.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] List move test - second of two messages 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:00:50 -0000 Marcus and everyone else, just use the new address, idna-update@ietf.org, from now on and everything should be fine. The various DMARC and other tests on mailing list addresses imply that some messages sent to idna-update@alvestrand.no and forward to the IETF list from there (as the second one from Harald was) may not get through. While that behavior is a matter of concern more generally, it is not a good topic for this mailing list. best, john --On Tuesday, April 11, 2017 13:38 -0700 Markus Scherer wrote: > I don't seem to have a message that says "first of two > messages". Is that bad? From rodger.combs@gmail.com Sun Apr 16 23:30:03 2017 Return-Path: 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 4EDFF12943B for ; Sun, 16 Apr 2017 23:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CVOb2HXJGU77 for ; Sun, 16 Apr 2017 23:30:01 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20096127010 for ; Sun, 16 Apr 2017 23:30:01 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so140435264ioi.2 for ; Sun, 16 Apr 2017 23:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=ADaY8SjblTSVFbNRmHzDoORFhMpZ/weOZKw1O58qLWM=; b=Y7C+xv6cUWruwCncA6tfJiTtzp5oEeWDzfMfgp8gMkH7UjCQf66UewnZUlNKafDD3f PBZgJRnehde+ZyWMDf2vicRmF1urb+z7UmJjzwObCZu68/fyIEsBvRdIzjMdDQ7OlVuX Hzy4QAfovAtnuwlVWHdnh9YNddSrIffXvsb8UJJ24z5U1xIeNgQvvqpe+oT46YGAjaVP NEKQucr67Pj0fZOBaijXMQdPxExVKtSyolilpIDwy21aENWkveQwXBaSOo3noI98ouda FGxanyGIS9WK6VH21XTRFDKC454w+Me2IwbS22TknXi9pPLDuvvnnItMe+6loE4BtN1n G+Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=ADaY8SjblTSVFbNRmHzDoORFhMpZ/weOZKw1O58qLWM=; b=I35Cy3hMmv1qvSDthvJHvwZtBrYC1joSNaB8aDAsy9yOxXYkir4JNuldRVx6j4nrkc JcmdaAQI8415Gz6bHI+m6PfLgTK6rF1SQtY8IyuDFUXx3ZjgSscUZ5qyS5umxWVZHYRv VronU868BmmCfGeGjCszbCCM4+UnHQgd/f9Wij7E4p/z80TyahQkXxW4DULlke7MKrph pm7luxpUl7g/W8DhGIipqYMG9qJPrECtF3kDbkHc01Crj6xUcyvOIJTtEJ9KBhAXWcWF R2+cUF79CMDsykWa4Mfd0KRq9xWnKsdSTIoTQJU8VARnk4QFswCBbgTtcgKlq9Xqg7V+ dRtg== X-Gm-Message-State: AN3rC/6WWndWCZaZdDRyhZFYcte/iUnGbRpCPuH9GNQ2BD2LuNg34uL5 BwtCDyl8pBpe0uV8YuI= X-Received: by 10.107.18.209 with SMTP id 78mr8838878ios.24.1492410600203; Sun, 16 Apr 2017 23:30:00 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:4160:a6cf:2743:c266? ([2601:243:504:643:4160:a6cf:2743:c266]) by smtp.gmail.com with ESMTPSA id 62sm2151909iou.10.2017.04.16.23.29.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Apr 2017 23:29:59 -0700 (PDT) From: Rodger Combs Content-Type: multipart/alternative; boundary="Apple-Mail=_05EB569C-7261-4B14-80E6-83E260C83397" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 17 Apr 2017 01:29:57 -0500 To: idna-update@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:00:14 -0000 --Apple-Mail=_05EB569C-7261-4B14-80E6-83E260C83397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, all! I've been reading a lot about IDN homoglyph attacks lately, and how = browser handling is generally deficient in this area in certain edge = cases. Most recently, there's been a lot of attention to the issue of = domain labels that are entirely within a single script, but contain all = glyphs that are confusable with those in another script. Firefox and = Chrome display the characters and allow the homoglyph attack, while = Safari prevents the recently-discussed case by not allowing Cyrillic in = IDN. Chromium's solution is to display Punycode if a label is entirely = composed of a hardcoded list of confusable-with-Latin characters. I find = all of these behaviors insufficient: Chromium's new solution relies on its hardcoded list being sufficient, = and one could imagine some edge case where a legitimate label is = composed entirely of the listed characters. Firefox's and Chrome's current behavior is clearly problematic, as it = allows for the attack. Safari's behavior completely fails users of Cyrillic, Greek, and = Ethiopic scripts, none of which are whitelisted. I've been thinking of potential solutions to this problem. In = particular, I'd like it to protect against attacks on all domains (not = just ASCII ones), and also protect against single-script confusables. = I've come up with a proposal, and I hope to get some feedback on it to = determine what complexities or edge cases I'm sure I'm overlooking. Proposed change: The ToASCII and ToUnicode algorithms remain the same, for the purposes = of storing and displaying domain labels as strings. However, ToASCII is = replaced with a new algorithm for the purposes of making DNS lookups. A new algorithm, ToDNSASCII, is defined, as follows: Perform steps 2 and 3 of ToASCII. Decompose the sequence using Unicode normalization form KD. Remove all combining code points from the sequence. Replace all instances of TR39 source-characters with their corresponding = target-strings in the sequence. Perform steps 5 through 8 of ToASCII. This algorithm effectively produces a "folded" version of the string, = similarly to a collation normalization. It is a lossy procedure, so the = resulting string must not be treated as a "canonical" name or displayed = to the user as if it were. When sending a label to a resolver, the ToDNSASCII algorithm is used = instead of ToASCII. If the resolver returns NXDOMAIN, retry using the = original ToASCII algorithm. When registering domains, writing zone files, or in similar = circumstances, perform both ToASCII and ToDNSASCII and store the results = of both if they differ. For all existing registered domains, register = ToDNSASCII(ToUnicode(domain)). If this name is already registered, = default precedence to the older registration, and notify the registrant = of the newer domain. This meets all of my goals: Allows any script or mix of scripts in any domain, with the owner able = to define any compatible representation as "canonical" Protects against all homoglyph attacks listed in TR39, including = single-script ones (e.g. "l" vs "1", which is entirely ASCII) Prevents confusion based on diacritics, without preventing their use Does not break compatibility with current user software Potential issues include (but are not limited to): Requires significant work in browsers, e-mail clients, and other = software that handles IDN Requires significant work from registrars and potentially DNS providers, = particularly during the initial migration Reopens the migration can of worms whenever TR39 is updated Makes DNS's representation of names impossible to convert losslessly = back to the canonical Unicode May create conflicts between domain owners who previously considered = their names legitimately distinct, but collide under ToDNSASCII Personally, I believe the security and usability benefits of this = concept would outweigh its costs if it were widely accepted, but I'll be = the first to admit that I'm little more than an armchair enthusiast in = the relevant topics, and would be entirely unsurprised if there were = unresolvable complexities I haven't foreseen, or if the ones I have were = impossible to overcome. Well... there you have it! Any feedback is appreciated! --Rodger --Apple-Mail=_05EB569C-7261-4B14-80E6-83E260C83397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello, all!

I've been reading a lot about IDN homoglyph attacks lately, = and how browser handling is generally deficient in this area in certain = edge cases. Most recently, there's been a lot of attention to the issue = of domain labels that are entirely within a single script, but contain = all glyphs that are confusable with those in another script. Firefox and = Chrome display the characters and allow the homoglyph attack, while = Safari prevents the recently-discussed case by not allowing Cyrillic in = IDN. Chromium's solution is to display Punycode if a label is entirely = composed of a hardcoded list of confusable-with-Latin characters. I find = all of these behaviors insufficient:

  • Chromium's new solution relies on its hardcoded list being = sufficient, and one could imagine some edge case where a legitimate = label is composed entirely of the listed characters.
  • Firefox's and Chrome's current behavior is clearly = problematic, as it allows for the attack.
  • Safari's = behavior completely fails users of Cyrillic, Greek, and Ethiopic = scripts, none of which are whitelisted.

I've been thinking of potential = solutions to this problem. In particular, I'd like it to protect against = attacks on all domains (not just ASCII ones), and also protect against = single-script confusables. I've come up with a proposal, and I hope to = get some feedback on it to determine what complexities or edge cases I'm = sure I'm overlooking.

Proposed change:

  • The ToASCII and = ToUnicode algorithms remain the same, for the purposes of storing and = displaying domain labels as strings. However, ToASCII is replaced with a = new algorithm for the purposes of making DNS lookups.
  • A= new algorithm, ToDNSASCII, is defined, as follows:
      • Perform steps 2 and 3 of ToASCII.
    1. Decompose= the sequence using Unicode normalization form KD.
    2. Remove all combining code points from the sequence.
    3. Replace all instances of TR39 source-characters with their = corresponding target-strings in the sequence.
    4. Perform = steps 5 through 8 of ToASCII.
  • This algorithm = effectively produces a "folded" version of the string, similarly to a = collation normalization. It is a lossy procedure, so the resulting = string must not be treated as a "canonical" name or displayed to the = user as if it were.
  • When sending a label to a = resolver, the ToDNSASCII algorithm is used instead of ToASCII. If the = resolver returns NXDOMAIN, retry using the original ToASCII = algorithm.
  • When registering domains, writing zone = files, or in similar circumstances, perform both ToASCII and ToDNSASCII = and store the results of both if they differ.
  • For all = existing registered domains, register ToDNSASCII(ToUnicode(domain)). If = this name is already registered, default precedence to the older = registration, and notify the registrant of the newer = domain.

This meets all of my goals:
  • Allows any script or mix of scripts = in any domain, with the owner able to define any compatible = representation as "canonical"
  • Protects against all = homoglyph attacks listed in TR39, including single-script ones (e.g. "l" = vs "1", which is entirely ASCII)
  • Prevents confusion = based on diacritics, without preventing their use
  • Does = not break compatibility with current user software

Potential issues = include (but are not limited to):
  • Requires significant work in = browsers, e-mail clients, and other software that handles IDN
  • Requires significant work from registrars and potentially DNS = providers, particularly during the initial migration
  • Reopens the migration can of worms whenever TR39 is = updated
  • Makes DNS's representation of names = impossible to convert losslessly back to the canonical Unicode
  • May create conflicts between domain owners who previously = considered their names legitimately distinct, but collide under = ToDNSASCII

Personally, I believe the security and usability benefits of = this concept would outweigh its costs if it were widely accepted, but = I'll be the first to admit that I'm little more than an armchair = enthusiast in the relevant topics, and would be entirely unsurprised if = there were unresolvable complexities I haven't foreseen, or if the ones = I have were impossible to overcome.

Well... there you have it! Any feedback = is appreciated!
--Rodger

= --Apple-Mail=_05EB569C-7261-4B14-80E6-83E260C83397-- From nobody Mon Apr 17 10:41:47 2017 Return-Path: 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 70FB9131700 for ; Mon, 17 Apr 2017 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudregistry-net.20150623.gappssmtp.com 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 pBa5vSwYC-9S for ; Mon, 17 Apr 2017 10:41:43 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0A0131701 for ; Mon, 17 Apr 2017 10:41:42 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id c80so18244857lfh.3 for ; Mon, 17 Apr 2017 10:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudregistry-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qPa+Qobl6grWM6FSCgYy5GVdS2rcG/f3trHhDLba6YY=; b=QdtztxN4wyceDr3YyGWqnetWepyZr77AcaDhYZMytM5AEDujsdpHn0Y8bVbjdD+7wQ SR4cEN8nPue1WLZxOlkatvNO78vnkueGjFc0ZTnnEgeJNs48f3wjps0hF9uUbWzQT5zj K6NpGy5utCfmkGss8d7sMsLN16V6Iat/CU150sM1xWLkrxbsQoNwsiL7V2EQRJEy2o4Z ECueyg6earvmboZ34aMs+ImSwfEO3NtRtWYAMcL+sE4rLE/brLdN/e5f+bZrzxzi0tk2 IK1neTiUUK9nQnHeE68HN+uFIzdgyQoFLtzjn9myX5uMpWXnG0zZslsx7Ob06QZpbuWX 9SMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qPa+Qobl6grWM6FSCgYy5GVdS2rcG/f3trHhDLba6YY=; b=YkaNZ8wpSkgcN5txSaSxH3wpqDNBVCpOKENa4EwTzz2TgJSQ6CG54RqQK+Fs5HtnNA HkQRkyF2GXZ6ZRZdhHAvH+3ntMrJkEmgeA0vzMxnHXbXXFYuD0q6+jN5T+6jJgAAzML+ S0Uug0XYiEHSjQvMuhprXdSOmEZY7CwKdQ9OccSym4x5AvU1/6AOpNep7q2O//ZGk02T N7rMfatdvB6KnHKqMDxkEPczyY4i6MGTyHQVxesvvwim1nF/XgBRDmMrfIfu6og5lGQ6 sAHx9OU8iIqo5JuMtBvz9tYJRBmXbff8uZ+97bJw6/LAEsYUR8Qec0paFZ1u/P4L1164 orQQ== X-Gm-Message-State: AN3rC/7w6DloCCGsPjCSjOBZ5rZQ2JnYRw8WLgQ6zjeqXtacamkpyqmo pFLbgd40C9WefsGKtPBOaOI4Q8fWVg== X-Received: by 10.46.20.87 with SMTP id 23mr163977lju.11.1492450900691; Mon, 17 Apr 2017 10:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.17 with HTTP; Mon, 17 Apr 2017 10:41:00 -0700 (PDT) In-Reply-To: References: From: Wil Tan Date: Tue, 18 Apr 2017 03:41:00 +1000 Message-ID: To: Rodger Combs Cc: idna-update@ietf.org Content-Type: multipart/alternative; boundary=f403045fb2d8c805c7054d604d46 Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:41:45 -0000 --f403045fb2d8c805c7054d604d46 Content-Type: text/plain; charset=UTF-8 Rodger, There are many issues that you have not listed, but the main showstopper is this: On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs wrote: > > - When sending a label to a resolver, the ToDNSASCII algorithm is used > instead of ToASCII. If the resolver returns NXDOMAIN, retry using the > original ToASCII algorithm. > > Updating resolver behaviour in this fashion is going to open up an ugly can of worms. Your mention of ToASCII and ToUnicode indicates that you may be looking at an outdated set of specifications (IDNA 2003). The updated specifications are generally known as IDNA 2008, and you may want to start from RFC5894, then 5890 - 5893. .wil --f403045fb2d8c805c7054d604d46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rodger,

There are many issues that you = have not listed, but the main showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.co= m> wrote:
  • When sending a label to a resolver, the ToDNSASCII algorithm is used = instead of ToASCII. If the resolver returns NXDOMAIN, retry using the origi= nal ToASCII algorithm.
Updating reso= lver behaviour in this fashion is going to open up an ugly can of worms.

Your mention of ToASCII and ToUnicode indicates that= you may be looking at an outdated set of specifications (IDNA 2003). The u= pdated specifications are generally known as IDNA 2008, and you may want to= start from RFC5894, then 5890 - 5893.

.wil
<= div>
--f403045fb2d8c805c7054d604d46-- From nobody Mon Apr 17 11:20:42 2017 Return-Path: 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 31C2F131751 for ; Mon, 17 Apr 2017 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1L4dgQTBTLTW for ; Mon, 17 Apr 2017 11:20:37 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDBC131571 for ; Mon, 17 Apr 2017 11:20:37 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id k87so139222908ioi.0 for ; Mon, 17 Apr 2017 11:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QWUIp88GMkXY5vfCt4VpxsQtGbo80poUDt5QXDYl2TE=; b=cqw+6rf4fUI1UwCMxjtfgbcIkdmGMGbDz3ywlWpL/t6AlGi56E5QXUiYR4BycccKwm 5xJGgd+1MpJjvVfrOp9L3ocwT4iLIN2sglrgpf5vl6wqNP3w0opKecaG3Aj9Rw5v0CrF 2uvq5/v6dG1YiDVdjrTPYJWlyhTtoHEiw6Wpj+/orpq+34w1AiYonEKlHNdFWEED8e0Q MnRDSvSQGMKLKwJHD/UlyNZOuYX2TIBX5ZxDnzvc6yzWc0yuRnx/S4ljp2CYNXkmF24Z ljENjgp8Y0Px2h2+9EoJC3whde9M07uDx4EgB6uVYtEcD5oWYrUtx5n6aaMDcZelHxJS Mm3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QWUIp88GMkXY5vfCt4VpxsQtGbo80poUDt5QXDYl2TE=; b=OIuEYHHV7Igui9oPJaOoi5GPE1z8iRGeApbxiTvGjUVkQ3nWFoPtropA7iIm0x5nuR 9nXVIaAAAo7MfscQCIRcd92RJEyD9zG92IE7cgFw1PlzemXeTT83kcG3aE4JFSf5Izhp p6h8IYt+7zWEH3DxVolNFDpMqcDOD2FREnC7BK4fQYjQnNaEbKDDH7pZgvZabxT0dxeK uq9Z7icfnmQHLJuF5Y7n3+98pWXXo51Lxhn0+NT2GGdC2iJ+DI3DexbY/i1f2ztzhg5i aZQnyC8pglSYjQ7eukDYI3spZlpOj7B6W5b99EYTPD5/oaSdFSRBTRamh2zVMtmi0yB6 10vg== X-Gm-Message-State: AN3rC/4drEGnJMpM3thGeE9quL+5savHeSfu7vFKOQDI44NUgZ/RK4ZD uei4RnYj0Pmc7dZyjFA= X-Received: by 10.36.1.213 with SMTP id 204mr9971005itk.51.1492453235374; Mon, 17 Apr 2017 11:20:35 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:4160:a6cf:2743:c266? ([2601:243:504:643:4160:a6cf:2743:c266]) by smtp.gmail.com with ESMTPSA id x78sm5216779iod.31.2017.04.17.11.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 11:20:34 -0700 (PDT) From: Rodger Combs Message-Id: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_68B95E3B-18F9-4159-A83D-CFD8BA01E6AD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 13:20:33 -0500 In-Reply-To: Cc: idna-update@ietf.org To: Wil Tan References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 18:20:40 -0000 --Apple-Mail=_68B95E3B-18F9-4159-A83D-CFD8BA01E6AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 17, 2017, at 12:41, Wil Tan wrote: >=20 > Rodger, >=20 > There are many issues that you have not listed, but the main = showstopper is this: >=20 > On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs > wrote: > When sending a label to a resolver, the ToDNSASCII algorithm is used = instead of ToASCII. If the resolver returns NXDOMAIN, retry using the = original ToASCII algorithm. > Updating resolver behaviour in this fashion is going to open up an = ugly can of worms. I'm actually surprised to hear that, since the concept allows for = backwards compatibility with existing behavior, both from the = user-agent's and the nameserver's perspective. I would've expected a = much larger can of worms in the transition process for registrars. What = issues would you anticipate with this particular change? >=20 > Your mention of ToASCII and ToUnicode indicates that you may be = looking at an outdated set of specifications (IDNA 2003). The updated = specifications are generally known as IDNA 2008, and you may want to = start from RFC5894, then 5890 - 5893. Ah, you're quite right; I was looking at RFC3490 and completely failed = to notice that it was marked as obsolete. I'll go update the Wikipedia = article on the topic (which still has a lot of 2003 terminology). It looks like the current procedures are sufficiently similar to the = 2003 ones that the added steps I proposed could be inserted between the = steps in sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 = of ToASCII. >=20 > .wil >=20 --Apple-Mail=_68B95E3B-18F9-4159-A83D-CFD8BA01E6AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 17, 2017, at 12:41, Wil Tan <wil@cloudregistry.net> wrote:

Rodger,

There are many issues that you have not listed, but the main = showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.com> = wrote:
  • When = sending a label to a resolver, the ToDNSASCII algorithm is used instead = of ToASCII. If the resolver returns NXDOMAIN, retry using the original = ToASCII algorithm.
Updating resolver behaviour in this fashion is going to open = up an ugly can of = worms.

I'm actually surprised to hear that, since the = concept allows for backwards compatibility with existing behavior, both = from the user-agent's and the nameserver's perspective. I would've = expected a much larger can of worms in the transition process for = registrars. What issues would you anticipate with this particular = change?


Your mention of ToASCII and ToUnicode indicates that you may = be looking at an outdated set of specifications (IDNA 2003). The updated = specifications are generally known as IDNA 2008, and you may want to = start from RFC5894, then 5890 - = 5893.

Ah, you're quite right; I was looking at RFC3490 = and completely failed to notice that it was marked as obsolete. I'll go = update the Wikipedia article on the topic (which still has a lot of 2003 = terminology).
It looks like the current procedures are = sufficiently similar to the 2003 ones that the added steps I proposed = could be inserted between the steps in sections 5.3 and 5.4 of RFC5891, = rather than replacing step 4 of ToASCII.


.wil


= --Apple-Mail=_68B95E3B-18F9-4159-A83D-CFD8BA01E6AD-- From nobody Mon Apr 17 12:57:40 2017 Return-Path: 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 356521200FC for ; Mon, 17 Apr 2017 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SBL=0.141, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com 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 WHIM1CvC2BCA for ; Mon, 17 Apr 2017 12:57:36 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36479124B0A for ; Mon, 17 Apr 2017 12:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1492459055; bh=+YxYIwgWVIdsS5jm83ySbOQsgBXSPcnmeOSs Y4ZL/2s=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=UYlYzr7Smnt55msY3FixeC1aP+xgUSFGOBypz1JKthoVEj yOyg+a6dndhsURgOQx8jdlpYg4Z0NpiYfvH91+G4JbXeQ2tXrfZCOIFFbv35qY/8Cu4 QOZRey+qJPZUzZJinYaWQD4NPAvHJOvH5/7Zn1njPbKJT+ZVKxARuy2RyThhnYDCpdd gY1ZYzrvuSHMjdc0XjqDb10QVPJMvMKw+HR1iehPFTDKyoRclEpqWdKNu1FsN0JSvVl +v3f1cpS+hNFpDMWASkxCxqDImApLV03rN8T+BsP+UfbjdqIrzw8DB9wJZkJzBi24vT ZLuvDYXu4L2FGO21nnbjh5IlzuZg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=pQKybSVI2ajDhcgi7FTAOV8KvL1QYk8L17gJMrbIe722EtxIlEHxfQQo1M00kL6+7wSoP9e/ihXrQGXLE5xFn0qzj11/gPdi1tlzygV9BekGCO5kXB9lLY2doYp2olXxB4BvZjNh7zYdlHpj+yJ37qIx6221lj2Osi/adP1naQVPD12EdPx5n3BJB6uqbYEFkgdXbNsMRvxKkQbnd1ovLwHo9V3J/dCZ9a71xoYlioYY6qQJh9u8CY5zUxund/p7bLbcDt3836mMlBdZjKLWCI2p/DizJCqE+KGADJug1YKqEpFq85mQA9yZURkT72LFBfUmWqNatVfKFRA/ZFWtXg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [199.241.146.179] (helo=[10.4.54.92]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1d0CmB-0006jR-1L for idna-update@ietf.org; Mon, 17 Apr 2017 15:57:31 -0400 To: idna-update@ietf.org References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> From: Asmus Freytag Message-ID: <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> Date: Mon, 17 Apr 2017 12:57:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> Content-Type: multipart/alternative; boundary="------------291C3D5A5D555221FB3AC97B" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2545e64a33c2ff5d08bb528e1cf4027fdacdca882bc43385d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 199.241.146.179 Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:57:38 -0000 This is a multi-part message in MIME format. --------------291C3D5A5D555221FB3AC97B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The suggestion: * Remove all combining code points from the sequence. is itself a non-starter. A./ On 4/17/2017 11:20 AM, Rodger Combs wrote: > >> On Apr 17, 2017, at 12:41, Wil Tan > > wrote: >> >> Rodger, >> >> There are many issues that you have not listed, but the main >> showstopper is this: >> >> On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs > > wrote: >> >> * When sending a label to a resolver, the ToDNSASCII algorithm >> is used instead of ToASCII. If the resolver returns NXDOMAIN, >> retry using the original ToASCII algorithm. >> >> Updating resolver behaviour in this fashion is going to open up an >> ugly can of worms. > > I'm actually surprised to hear that, since the concept allows for > backwards compatibility with existing behavior, both from the > user-agent's and the nameserver's perspective. I would've expected a > much larger can of worms in the transition process for registrars. > What issues would you anticipate with this particular change? > >> >> Your mention of ToASCII and ToUnicode indicates that you may be >> looking at an outdated set of specifications (IDNA 2003). The updated >> specifications are generally known as IDNA 2008, and you may want to >> start from RFC5894, then 5890 - 5893. > > Ah, you're quite right; I was looking at RFC3490 and completely failed > to notice that it was marked as obsolete. I'll go update the Wikipedia > article on the topic (which still has a lot of 2003 terminology). > It looks like the current procedures are sufficiently similar to the > 2003 ones that the added steps I proposed could be inserted between > the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing > step 4 of ToASCII. > >> >> .wil >> > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --------------291C3D5A5D555221FB3AC97B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
The suggestion:

  * Remove all combining code points from the sequence.

is itself a non-starter.

A./

On 4/17/2017 11:20 AM, Rodger Combs wrote:

On Apr 17, 2017, at 12:41, Wil Tan <wil@cloudregistry.net> wrote:

Rodger,

There are many issues that you have not listed, but the main showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.com> wrote:
  • When sending a label to a resolver, the ToDNSASCII algorithm is used instead of ToASCII. If the resolver returns NXDOMAIN, retry using the original ToASCII algorithm.
Updating resolver behaviour in this fashion is going to open up an ugly can of worms.

I'm actually surprised to hear that, since the concept allows for backwards compatibility with existing behavior, both from the user-agent's and the nameserver's perspective. I would've expected a much larger can of worms in the transition process for registrars. What issues would you anticipate with this particular change?


Your mention of ToASCII and ToUnicode indicates that you may be looking at an outdated set of specifications (IDNA 2003). The updated specifications are generally known as IDNA 2008, and you may want to start from RFC5894, then 5890 - 5893.

Ah, you're quite right; I was looking at RFC3490 and completely failed to notice that it was marked as obsolete. I'll go update the Wikipedia article on the topic (which still has a lot of 2003 terminology).
It looks like the current procedures are sufficiently similar to the 2003 ones that the added steps I proposed could be inserted between the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII.


.wil




_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


--------------291C3D5A5D555221FB3AC97B-- From nobody Mon Apr 17 18:48:24 2017 Return-Path: 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 1A0EC128D44 for ; Mon, 17 Apr 2017 18:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tBQgBK-ro_pT for ; Mon, 17 Apr 2017 18:48:20 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B627F1200C5 for ; Mon, 17 Apr 2017 18:48:20 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id r16so170778579ioi.2 for ; Mon, 17 Apr 2017 18:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VjhAmM82aKEHMvLI3sL2sC+9BmnqKtGjnF2+RrN1mgg=; b=pUencIUFzJSXKQr4TRD4m6CzXb3UoNRw2DbufwcInYSJfy/7viz47EbGrhCkhQHA83 MvAfmtawiVQBPk3Rl88UH+5bXtVU6o07uB2DWDNkRzKxLI0AukpaWgz/vULw7eele9yN w3Sh0wxuPflY18g5Fit3SBx/CBrEKyYdWFH1qm1Bm1ZHmmwSEO+rHxZxpbnpwZzzIyGi GFRS0cIgvk9arnAS8MlPV54HGEn+aVCDWh7G/eMG9pW8wxiEYuAEFjjNPKK1SN66Dv3B Df5suHmd9Nhg/+DSn9YT5oDxfUdKCXMkQp/jTz5ozAX1lI74uu3PkPQvbpQsRsH9zjtB 73zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VjhAmM82aKEHMvLI3sL2sC+9BmnqKtGjnF2+RrN1mgg=; b=J3Ze1Xf96po4zICoreJdeNajjZwpVUKvfElNv8Q9fdiJEKCWkxyVICf6p5YOcEvP/5 8fmntThnFfZl1vPwViVrkD8k8kP9W+K0X7jLFMqGVeAONcStAqvimDh40AbwK8ExLRBe GmKLLBQS7iu1amJDI5MPEpp06IVs2AEAtrUAPBycVF0zWKgmuhssBcbEt0yYFN3SQujE papLF8t0uUPXlje7zHC97j5Lutzhj4Ebox8EB/dCfO7O9ySrS033K9XPMfZAPkXLCBPN dj7ReKjDmluPWJNY9gbskkt4aNfM2XqmPQ+A35v0FFSZgh3hdG/KuSbkIVERJ+Jk3vI5 8xWQ== X-Gm-Message-State: AN3rC/699BqEJAOP6eXPozvcW+mUKBrMxcdatsL9bq2i/DA1WkwxSgX6 wmdqpWcDy39EzVrVePg= X-Received: by 10.36.32.138 with SMTP id t132mr5826799itt.89.1492480099976; Mon, 17 Apr 2017 18:48:19 -0700 (PDT) Received: from ?IPv6:2600:380:c416:f910:d439:1a81:33eb:bfe8? ([2600:380:c416:f910:d439:1a81:33eb:bfe8]) by smtp.gmail.com with ESMTPSA id v23sm4933416ioi.61.2017.04.17.18.48.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 18:48:19 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Mime-Version: 1.0 (1.0) From: Rodger Combs X-Mailer: iPhone Mail (14E304) In-Reply-To: <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> Date: Mon, 17 Apr 2017 20:48:17 -0500 Cc: idna-update@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> To: Asmus Freytag Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:48:23 -0000 --Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Apr 17, 2017, at 14:57, Asmus Freytag wrote: >=20 > The suggestion: >=20 > * Remove all combining code points from the sequence. >=20 > is itself a non-starter. That step is more or less separable from the rest of the concept, but I'm cu= rious why you say that. Is it common for legitimate domains to differ only b= y combining code points after NKFD? Note that this would not prevent _displa= y_ of diacritics. >=20 > A./ >=20 >> On 4/17/2017 11:20 AM, Rodger Combs wrote: >>=20 >>> On Apr 17, 2017, at 12:41, Wil Tan wrote: >>>=20 >>> Rodger, >>>=20 >>> There are many issues that you have not listed, but the main showstopper= is this: >>>=20 >>>> On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs w= rote: >>>> When sending a label to a resolver, the ToDNSASCII algorithm is used in= stead of ToASCII. If the resolver returns NXDOMAIN, retry using the original= ToASCII algorithm. >>> Updating resolver behaviour in this fashion is going to open up an ugly c= an of worms. >>=20 >> I'm actually surprised to hear that, since the concept allows for backwar= ds compatibility with existing behavior, both from the user-agent's and the n= ameserver's perspective. I would've expected a much larger can of worms in t= he transition process for registrars. What issues would you anticipate with t= his particular change? >>=20 >>>=20 >>> Your mention of ToASCII and ToUnicode indicates that you may be looking a= t an outdated set of specifications (IDNA 2003). The updated specifications a= re generally known as IDNA 2008, and you may want to start from RFC5894, the= n 5890 - 5893. >>=20 >> Ah, you're quite right; I was looking at RFC3490 and completely failed to= notice that it was marked as obsolete. I'll go update the Wikipedia article= on the topic (which still has a lot of 2003 terminology). >> It looks like the current procedures are sufficiently similar to the 2003= ones that the added steps I proposed could be inserted between the steps in= sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII. >>=20 >>>=20 >>> .wil >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update >=20 > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On Apr 17, 2017, at 14:57, Asmus Freytag <asmusf@ix.netcom.com> wrote:

The suggestion:

  * Remove all combining code points from the sequence.

is itself a non-starter.

That step is more or less separable from the rest of the concept, but I'm curious why you say that. Is it common for legitimate domains to differ only by combining code points after NKFD? Note that this would not prevent _display_ of diacritics.


A./

On 4/17/2017 11:20 AM, Rodger Combs wrote:

On Apr 17, 2017, at 12:41, Wil Tan <wil@cloudregistry.net> wrote:

Rodger,

There are many issues that you have not listed, but the main showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.com> wrote:
  • When sending a label to a resolver, the ToDNSASCII algorithm is used instead of ToASCII. If the resolver returns NXDOMAIN, retry using the original ToASCII algorithm.
Updating resolver behaviour in this fashion is going to open up an ugly can of worms.

I'm actually surprised to hear that, since the concept allows for backwards compatibility with existing behavior, both from the user-agent's and the nameserver's perspective. I would've expected a much larger can of worms in the transition process for registrars. What issues would you anticipate with this particular change?


Your mention of ToASCII and ToUnicode indicates that you may be looking at an outdated set of specifications (IDNA 2003). The updated specifications are generally known as IDNA 2008, and you may want to start from RFC5894, then 5890 - 5893.

Ah, you're quite right; I was looking at RFC3490 and completely failed to notice that it was marked as obsolete. I'll go update the Wikipedia article on the topic (which still has a lot of 2003 terminology).
It looks like the current procedures are sufficiently similar to the 2003 ones that the added steps I proposed could be inserted between the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII.


.wil




_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update
--Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2-- From nobody Mon Apr 17 19:00:31 2017 Return-Path: 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 606BA128616 for ; Mon, 17 Apr 2017 19:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9_bqGRW-mQHU for ; Mon, 17 Apr 2017 19:00:28 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264E81293F2 for ; Mon, 17 Apr 2017 19:00:28 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id k87so30080472ioi.0 for ; Mon, 17 Apr 2017 19:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=VjhAmM82aKEHMvLI3sL2sC+9BmnqKtGjnF2+RrN1mgg=; b=lT8JmOmqvrK9GoLdIgZS15ePCpxKdMzcJHGiDosNJGeZj0sUCkoDKpGuJzfkR+Lt4Z YWn1XD2TRsXubRVoXQjshLWtfNgDHGe64T3Oh2K23mwHfCPEuallg0Q+EMwp22HK/Kaz USamaDOfw6gF+t9fnv9xgptjxqLmkm2OQsnB95OG3oJnZZ4gMQ1KfJKIJHj8BuzHmFc3 wg+hO2FIeNNss4uYf0KwmIVG9ay6ji1RsSHljsUynpRBwH4g6r6KVRW0Fn7BgfnDU3Tq 9JUT6xv886LDxM0saoTNTlZ3dufj6qDuYUownwHYc7wJCEGSDp/c2vpBDxZQ8tobwTJE q+ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=VjhAmM82aKEHMvLI3sL2sC+9BmnqKtGjnF2+RrN1mgg=; b=iDyCPUsxh/5RdMUCkhHX7+sfGVh29RnX4B0tBvFsuhQp0MWDDFvqWxLMGXE7AytrU0 TuvDsJDyv0QGP+L7s61PP6oL5tOTH6lnCs2gfCbO/idP5naVrB6V576HOiC45QuQ6Bqq O5BzCACcj/Lm3j52o2SIUJsBk7dgIyaNnTPXwpQK7udcDii2qb3cedJo8QY0y9zGlhh/ lqnwsY8x6zcAYAyJwRIFS2TbMG92ron5t78JIXYsjN1VG4fk0MERTziR4fl+vh2ltAqa zROsQ36MO709EeeIBqPQdy6AsZc2/FTVipd1Wp45BtgJEWshEM+92pMW07H7ekh2r4AI MffA== X-Gm-Message-State: AN3rC/7XTs426FpRyoCajtluEfRJaUxZR6ZmfKwYjnzQqLT1Unp/uBo/ a4mLly97ruxJE1sFyYM= X-Received: by 10.107.130.104 with SMTP id e101mr13131525iod.118.1492480827275; Mon, 17 Apr 2017 19:00:27 -0700 (PDT) Received: from ?IPv6:2600:380:c416:f910:d439:1a81:33eb:bfe8? ([2600:380:c416:f910:d439:1a81:33eb:bfe8]) by smtp.gmail.com with ESMTPSA id 34sm5773456ioh.56.2017.04.17.19.00.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 19:00:27 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Content-Transfer-Encoding: 7bit From: Rodger Combs Mime-Version: 1.0 (1.0) Date: Mon, 17 Apr 2017 20:48:17 -0500 Message-Id: <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> Cc: idna-update@ietf.org In-Reply-To: <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> To: Asmus Freytag X-Mailer: iPhone Mail (14E304) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 02:00:30 -0000 --Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Apr 17, 2017, at 14:57, Asmus Freytag wrote: >=20 > The suggestion: >=20 > * Remove all combining code points from the sequence. >=20 > is itself a non-starter. That step is more or less separable from the rest of the concept, but I'm cu= rious why you say that. Is it common for legitimate domains to differ only b= y combining code points after NKFD? Note that this would not prevent _displa= y_ of diacritics. >=20 > A./ >=20 >> On 4/17/2017 11:20 AM, Rodger Combs wrote: >>=20 >>> On Apr 17, 2017, at 12:41, Wil Tan wrote: >>>=20 >>> Rodger, >>>=20 >>> There are many issues that you have not listed, but the main showstopper= is this: >>>=20 >>>> On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs w= rote: >>>> When sending a label to a resolver, the ToDNSASCII algorithm is used in= stead of ToASCII. If the resolver returns NXDOMAIN, retry using the original= ToASCII algorithm. >>> Updating resolver behaviour in this fashion is going to open up an ugly c= an of worms. >>=20 >> I'm actually surprised to hear that, since the concept allows for backwar= ds compatibility with existing behavior, both from the user-agent's and the n= ameserver's perspective. I would've expected a much larger can of worms in t= he transition process for registrars. What issues would you anticipate with t= his particular change? >>=20 >>>=20 >>> Your mention of ToASCII and ToUnicode indicates that you may be looking a= t an outdated set of specifications (IDNA 2003). The updated specifications a= re generally known as IDNA 2008, and you may want to start from RFC5894, the= n 5890 - 5893. >>=20 >> Ah, you're quite right; I was looking at RFC3490 and completely failed to= notice that it was marked as obsolete. I'll go update the Wikipedia article= on the topic (which still has a lot of 2003 terminology). >> It looks like the current procedures are sufficiently similar to the 2003= ones that the added steps I proposed could be inserted between the steps in= sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII. >>=20 >>>=20 >>> .wil >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update >=20 > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On Apr 17, 2017, at 14:57, Asmus Freytag <asmusf@ix.netcom.com> wrote:

The suggestion:

  * Remove all combining code points from the sequence.

is itself a non-starter.

That step is more or less separable from the rest of the concept, but I'm curious why you say that. Is it common for legitimate domains to differ only by combining code points after NKFD? Note that this would not prevent _display_ of diacritics.


A./

On 4/17/2017 11:20 AM, Rodger Combs wrote:

On Apr 17, 2017, at 12:41, Wil Tan <wil@cloudregistry.net> wrote:

Rodger,

There are many issues that you have not listed, but the main showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.com> wrote:
  • When sending a label to a resolver, the ToDNSASCII algorithm is used instead of ToASCII. If the resolver returns NXDOMAIN, retry using the original ToASCII algorithm.
Updating resolver behaviour in this fashion is going to open up an ugly can of worms.

I'm actually surprised to hear that, since the concept allows for backwards compatibility with existing behavior, both from the user-agent's and the nameserver's perspective. I would've expected a much larger can of worms in the transition process for registrars. What issues would you anticipate with this particular change?


Your mention of ToASCII and ToUnicode indicates that you may be looking at an outdated set of specifications (IDNA 2003). The updated specifications are generally known as IDNA 2008, and you may want to start from RFC5894, then 5890 - 5893.

Ah, you're quite right; I was looking at RFC3490 and completely failed to notice that it was marked as obsolete. I'll go update the Wikipedia article on the topic (which still has a lot of 2003 terminology).
It looks like the current procedures are sufficiently similar to the 2003 ones that the added steps I proposed could be inserted between the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII.


.wil




_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update
--Apple-Mail-E6BB8C02-DBAF-422F-A486-8836EF9411F2-- From nobody Mon Apr 17 19:42:10 2017 Return-Path: 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 1028B129411 for ; Mon, 17 Apr 2017 19:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SBL=0.141] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com 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 0ZZ0FK3XUkOu for ; Mon, 17 Apr 2017 19:42:08 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE060129426 for ; Mon, 17 Apr 2017 19:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1492483327; bh=DkMi7OQ0iGAwEazZ+WBxNl80mKOu//cH07Zi GeOs3x0=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=hjxWYdwtUfTrOYMNS5BwKz3jYFFNeY7NzI3sir3h6HmkdG WpnNsXaQ1KHvmegHWuHM/hvHfCEngSg/TAk/dU2ELgILatb78NrBwK/0D8MEKKiIWVP aPBer5Q+kWCOFvciY5+pkwBXFfCi1rNMOt48O0Kum3DV6ezNw8L30msY/jw36tDhFuC pU4dJSYVzNrxvaw8WDA5LWJPo5UIDJBZm0A/K4ssUwRqhrHGi5vj6OF8U98P9sKV98A z2Tu7jHWI1BMYBxwV7j7GdeaA+Z9BK79OAY11KZ3EQE6lkVVDsLJ7sQqwRExQP7nN4J xrGqPBMW4XSnTuWT0+Y6VwdXOAyw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=rWdLGEL/1o93iUcjrTmFaTfWlf2MaG0a+jDzQG6pd1amtACQio7/O7p1QRVQ54vavIXS6KNaDcMQdurx8qe6oJ4cGEC4PiTFsRngWBAqN0aFu2QfBjdOoxD+y7G6ItkhMSBrjFiCRrCB3dExWWUtwF6wmVCebprgl5en3szjm+j9Im7BVgJRts1KCom4Inx9R+BfOzvhhZ1V4e3on/K8xvZgFr4oaQdi8jWtbafR4e0LuI8ANYh3J6VvzGB93CXFDScMuCkJHhqNGudJsPGlHTHlmz5nmloC8Ienu4hsHEkbIIUatW4Tw/4nf1XafoCm7TVzGyvSOZB4PdHcarMtiw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [199.241.146.179] (helo=[10.4.54.92]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1d0J5e-0003pU-Qx for idna-update@ietf.org; Mon, 17 Apr 2017 22:42:03 -0400 To: idna-update@ietf.org References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> From: Asmus Freytag Message-ID: Date: Mon, 17 Apr 2017 19:42:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> Content-Type: multipart/alternative; boundary="------------B23F5E77CFB796B9B73FC5D0" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2545e64a33c2ff5d0184f54cb9f9e03155aed257b313db47a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 199.241.146.179 Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 02:42:10 -0000 This is a multi-part message in MIME format. --------------B23F5E77CFB796B9B73FC5D0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/2017 6:48 PM, Rodger Combs wrote: > > On Apr 17, 2017, at 14:57, Asmus Freytag > wrote: > >> The suggestion: >> >> * Remove all combining code points from the sequence. >> >> is itself a non-starter. > > That step is more or less separable from the rest of the concept, but > I'm curious why you say that. Is it common for legitimate domains to > differ only by combining code points after NKFD? Yes. > Note that this would not prevent _display_ of diacritics. Your choice of terms tells me that you think combining marks and diacritics are the same thing. A./ > >> >> A./ >> >> On 4/17/2017 11:20 AM, Rodger Combs wrote: >>> >>>> On Apr 17, 2017, at 12:41, Wil Tan >>> > wrote: >>>> >>>> Rodger, >>>> >>>> There are many issues that you have not listed, but the main >>>> showstopper is this: >>>> >>>> On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs >>>> > wrote: >>>> >>>> * When sending a label to a resolver, the ToDNSASCII >>>> algorithm is used instead of ToASCII. If the resolver >>>> returns NXDOMAIN, retry using the original ToASCII algorithm. >>>> >>>> Updating resolver behaviour in this fashion is going to open up an >>>> ugly can of worms. >>> >>> I'm actually surprised to hear that, since the concept allows for >>> backwards compatibility with existing behavior, both from the >>> user-agent's and the nameserver's perspective. I would've expected a >>> much larger can of worms in the transition process for registrars. >>> What issues would you anticipate with this particular change? >>> >>>> >>>> Your mention of ToASCII and ToUnicode indicates that you may be >>>> looking at an outdated set of specifications (IDNA 2003). The >>>> updated specifications are generally known as IDNA 2008, and you >>>> may want to start from RFC5894, then 5890 - 5893. >>> >>> Ah, you're quite right; I was looking at RFC3490 and completely >>> failed to notice that it was marked as obsolete. I'll go update the >>> Wikipedia article on the topic (which still has a lot of 2003 >>> terminology). >>> It looks like the current procedures are sufficiently similar to the >>> 2003 ones that the added steps I proposed could be inserted between >>> the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing >>> step 4 of ToASCII. >>> >>>> >>>> .wil >>>> >>> >>> >>> >>> _______________________________________________ >>> IDNA-UPDATE mailing list >>> IDNA-UPDATE@ietf.org >>> https://www.ietf.org/mailman/listinfo/idna-update >> >> >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --------------B23F5E77CFB796B9B73FC5D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/17/2017 6:48 PM, Rodger Combs wrote:

On Apr 17, 2017, at 14:57, Asmus Freytag <asmusf@ix.netcom.com> wrote:

The suggestion:

  * Remove all combining code points from the sequence.

is itself a non-starter.

That step is more or less separable from the rest of the concept, but I'm curious why you say that. Is it common for legitimate domains to differ only by combining code points after NKFD?

Yes.

Note that this would not prevent _display_ of diacritics.

Your choice of terms tells me that you think combining marks and diacritics are the same thing.

A./


A./

On 4/17/2017 11:20 AM, Rodger Combs wrote:

On Apr 17, 2017, at 12:41, Wil Tan <wil@cloudregistry.net> wrote:

Rodger,

There are many issues that you have not listed, but the main showstopper is this:

On Mon, Apr 17, 2017 at 4:29 PM, Rodger Combs <rodger.combs@gmail.com> wrote:
  • When sending a label to a resolver, the ToDNSASCII algorithm is used instead of ToASCII. If the resolver returns NXDOMAIN, retry using the original ToASCII algorithm.
Updating resolver behaviour in this fashion is going to open up an ugly can of worms.

I'm actually surprised to hear that, since the concept allows for backwards compatibility with existing behavior, both from the user-agent's and the nameserver's perspective. I would've expected a much larger can of worms in the transition process for registrars. What issues would you anticipate with this particular change?


Your mention of ToASCII and ToUnicode indicates that you may be looking at an outdated set of specifications (IDNA 2003). The updated specifications are generally known as IDNA 2008, and you may want to start from RFC5894, then 5890 - 5893.

Ah, you're quite right; I was looking at RFC3490 and completely failed to notice that it was marked as obsolete. I'll go update the Wikipedia article on the topic (which still has a lot of 2003 terminology).
It looks like the current procedures are sufficiently similar to the 2003 ones that the added steps I proposed could be inserted between the steps in sections 5.3 and 5.4 of RFC5891, rather than replacing step 4 of ToASCII.


.wil




_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


--------------B23F5E77CFB796B9B73FC5D0-- From nobody Mon Apr 17 20:58:09 2017 Return-Path: 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 A59EE12869B for ; Mon, 17 Apr 2017 20:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 4e7zWcM1aQGG for ; Mon, 17 Apr 2017 20:58:05 -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 9CCAB128DF3 for ; Mon, 17 Apr 2017 20:58:05 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0KHD-0008gr-8f; Mon, 17 Apr 2017 23:58:03 -0400 Date: Mon, 17 Apr 2017 23:57:56 -0400 From: John C Klensin To: Rodger Combs , idna-update@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 03:58:08 -0000 --On Monday, April 17, 2017 01:29 -0500 Rodger Combs wrote: > Hello, all! >=20 > I've been reading a lot about IDN homoglyph attacks lately, > and how browser handling is generally deficient in this area > in certain edge cases. Most recently, there's been a lot of > attention to the issue of domain labels that are entirely > within a single script, but contain all glyphs that are > confusable with those in another script. Rodger, I hope you understand that is really old news, with examples introduced into ICANN meetings by 2002. You should also not make the mistake of assuming that UTS#39 either covers all important cases or represents consensus in the IDNA and DNS communities. > Firefox and Chrome > display the characters and allow the homoglyph attack, while > Safari prevents the recently-discussed case by not allowing > Cyrillic in IDN. One of the sources of this "problem" is that Greek, Latin, and Cyrillic are very closely related due to the derivation of the latter two and a lot of borrowed, even if then somewhat transfored characters, facts known to many schoolchildren. However, their are not the only set of scripts with such relationships and the very notion of a "script" and whether two related writing systems use the same script or different once can be a little subject and arbitrary, not unlike the question of whether two groups of people speak different languages or dialects of the same one. It is probably also worth noting that almost every script uses a more or less vertical stroke and/or a more or less horizontal or diagonal one, and/or some sort of round thing as a letter or digit. So, yes, one can solve some problems by rejecting Cyrillic and even more by rejecting Cyrillic and Greek script or, in principle, Latin script and either of the other two. One can then start looking for other sets (pairs of more) or scripts and figure out which ones are most important. But, sooner rather than later, one doesn't have IDNs at all but a moderately small collection of scripts that are preferred, perhaps for political reasons. > Chromium's solution is to display Punycode if > a label is entirely composed of a hardcoded list of > confusable-with-Latin characters. That is the Greek-Latin-Cyrillic European bias described above. It is probably unreasonable to compare everything with Latin and then assume one is done. One can (and we do) have similarities or confusion among other sets of scripts, especially those with relatively recent common origins, as well. > I find all of these behaviors insufficient I hope you don't think you are going to find a single, magical, solution because, due to both the way various scripts developed from each other and then are used in different ways in different languages and to issue with human perception and artistic type styles, there is almost certainly no such solution. > Chromium's new solution relies on its hardcoded list being > sufficient, and one could imagine some edge case where a > legitimate label is composed entirely of the listed = characters. > Firefox's and Chrome's current behavior is clearly > problematic, as it allows for the attack. Safari's behavior > completely fails users of Cyrillic, Greek, and Ethiopic > scripts, none of which are whitelisted. Yes. Again, the quest for magical and simple solutions is never going to yield completely satisfactory results. > I've been thinking of potential solutions to this problem. In > particular, I'd like it to protect against attacks on all > domains (not just ASCII ones), and also protect against > single-script confusables. I've come up with a proposal, and I > hope to get some feedback on it to determine what complexities > or edge cases I'm sure I'm overlooking. >=20 > Proposed change: >=20 > The ToASCII and ToUnicode algorithms remain the same, for the > purposes of storing and displaying domain labels as strings. > However, ToASCII is replaced with a new algorithm for the > purposes of making DNS lookups. A new algorithm, ToDNSASCII, > is defined, as follows: See Will's note about IDNA2008. Note that by forbidding symbols and everything else that is not analogous to a letter or digit, it eliminates many cases your analysis doesn't appear to have even gotten to yet. > Perform steps 2 and 3 of ToASCII. > Decompose the sequence using Unicode normalization form KD. > Remove all combining code points from the sequence. Especially with NFKD, your eliminated a lot of useful and important characters. Latin script provides particular lurid examples: with a few exceptions like "=C3=B8" (U+00F8) (and the = fact that it is an exception is actually a problem), you've eliminated substantially all Latin-script letters that are in any way "decorated" (diacritical marks of all flavors included but note Asmus's second note). As Asmus says, non-starter. > Replace all instances of TR39 source-characters with their > corresponding target-strings in the sequence. Perform steps 5 > through 8 of ToASCII. > This algorithm effectively produces a "folded" version of the > string, similarly to a collation normalization. It is a lossy > procedure, so the resulting string must not be treated as a > "canonical" name or displayed to the user as if it were. When > sending a label to a resolver, the ToDNSASCII algorithm is > used instead of ToASCII. If the resolver returns NXDOMAIN, > retry using the original ToASCII algorithm. During the development of IDNA (both versions) the DNS folks were very clear (for good reason, IMO) that a systems that relied on looking up one string and, if that failed, looking up another was a complete non-starter for both performance and DNS design philosophy reasons. Variations on what you are suggesting were considered and rejected for that and other reasons. > When registering > domains, writing zone files, or in similar circumstances, > perform both ToASCII and ToDNSASCII and store the results of > both if they differ.=20 This doesn't work either. It is a variation on the idea of "variant" as most recently interpreted by ICANN and depends on both names being registered to the same party. That words better for some protocols than others, can be harder to manage (at least for things other than web sites) than people imagine, and we've had history of arbitrators and courts separating pairs of names that the original registrants thought were bound together forever. Your idea at least has the advantage over separate others of guaranteeing that problem labels come in pairs rather than creating combinatorial explosions at a single subtree of the DNS. =20 > For all existing registered domains, > register ToDNSASCII(ToUnicode(domain)). If this name is > already registered, default precedence to the older > registration, and notify the registrant of the newer domain. Unless I misunderstand you, as soon as both strings are registered, especially to two different parties, you create an opportunity for exactly the attacks you are trying to prevent. Or, if you mean "block the proposed new registration" when you say "notify the registrant", you've blocked a lot of perfectly reasonable names for no really good reason. Again, you don't even need to go outside Latin script to see the problem: Applying NFKD to "f=C3=BCr" gives U+0066 U+0075 U+0308 U+0072. Then, if I understand your algorithm correctly, you discard the combining diaeresis, leading to "fur" for which there appear to be second-level registrations in a number of domains. And many people would argue that "f=C3=BCr" and "fur" are not even confusable, at last unless one believes that any decorated character can be confused with the associated base one and any other decorated character with the same base. >... best, john From nobody Mon Apr 17 22:01:03 2017 Return-Path: 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 B25751292D3 for ; Mon, 17 Apr 2017 22:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FVgf6zA5WULd for ; Mon, 17 Apr 2017 22:00:58 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6DC126CC7 for ; Mon, 17 Apr 2017 22:00:58 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id a103so178119946ioj.1 for ; Mon, 17 Apr 2017 22:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FGhu87JuIeWMZzddmoggpA7RMC1FvBEabXoGq0DveZM=; b=iuEW0q6R6sKEI7qg6cNY2Oubx4FfXgZWcyBgJkIQ+UT8cIK81S87FVQ4zqHthZtAE2 fMZl3LvLU0ixD3c4NxuEQc5RtFcCwuEZEAV/tlKNfmvgOjkmYevBxBdbUtvVG29m1H0C 4mAJ5yHEbB5DisDpkmhUtbpxhX73RoAhsr4MF0AzUxQMrY3oASkvH7wGo6WQNgBQfEaW 1Kp7rmNSdzHxYB+mlGO/OnxnNp60LVlrNTLko1mSERy5B6TRBV2JvvouSnz13zxT8v30 7DKm1cxZMNZJEhtX4sp5LBKRjY5coA5vBX++0ddZDvBvKOvzWK3RdO/hi/yiJdWAR1K+ Q7jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FGhu87JuIeWMZzddmoggpA7RMC1FvBEabXoGq0DveZM=; b=YLl7Yj1La7Gz0uBp2cbsYWq+nS2scjKJ2K7WQ6Ceaf80qXlC3eJZARzsNwN7KvvTTe L9XDX9p+Xbwr0CeturgTZ3hrDSvA+pOp4Y6mgqklKXBLmbJi7e+oGQNBLWzWAnz+p0l2 bbRb5onwFuwr0UdBM40rt+/MeWdEAKIN7BXvkNoxju26LQm+Qvp49CTqw5mPnpizuN36 HmtmmmDWGpMTtpxg/COq2sUdqPORqAWsNwjLEi+w3B2nACtYCqL1aqmzz85l6wHQbRHa ZlEuAEfNB+FG5Cf6UUOWdKuHJKHtjJleqV9ouWQ7A9ip2WX09ltwMWCXYdJL138OfI4y nWaw== X-Gm-Message-State: AN3rC/4aZR4dKMeLJG0N5IzEOHZ3fK81rcrXVP1+S+8AFYvC93OQ6Oqg zd9DaWte1XMHzg== X-Received: by 10.107.6.6 with SMTP id 6mr11714843iog.78.1492491657293; Mon, 17 Apr 2017 22:00:57 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:3c9c:1d39:5c75:4294? ([2601:243:504:643:3c9c:1d39:5c75:4294]) by smtp.gmail.com with ESMTPSA id h42sm5982366ioi.16.2017.04.17.22.00.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 22:00:56 -0700 (PDT) From: Rodger Combs Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4BF6B295-7F93-4F27-9978-FE6C7DA94B8A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 00:00:55 -0500 In-Reply-To: Cc: idna-update@ietf.org To: John C Klensin References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:01:00 -0000 --Apple-Mail=_4BF6B295-7F93-4F27-9978-FE6C7DA94B8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the detailed response; I really appreciate the context! I = know this is a complex problem, and I hope I haven't been involuntarily = implying that it seemed otherwise. I have no delusions of my concepts = approaching perfection; merely that with some work, improvements could = be made over what browsers currently implement. A few specific replies inline, but here's a refreshed proposal that I = believe addresses the technical concerns you brought up: Make no change to names as used in DNS. Instead, each registry maintains an internal database of "folded" = variants of domains, and refuses new domains which "fold" to a value = matching that of an existing one. This solves backwards-compatibility, performance, DNS design, and = "variant" management problems. Remaining concerns include (but remain = distinctly not limited to): Registries would actually have to do this. If domain pairs differing only by combining marks are indeed commonly = legitimate, then the relevant stripping would need to be removed (see = bottom reply). The incomplete nature and lack of consensus around UTS#39. The action to take if existing domains collide. The action to take if existing domains became colliding after future = updates to the confusables list. Exceptions like U+00F8. At this point, I think the best thing I could do is probably grab a list = of domains (.com, perhaps), write up a script to perform this algorithm, = and see what collisions come out. If they turn out to be predominantly = legitimate, then there's probably no point pursuing this further. If = there are very few, or the bulk appear to be illegitimate, then this = might be worth hashing out in more detail. Does that seem reasonable? > On Apr 17, 2017, at 22:57, John C Klensin wrote: >=20 >=20 >=20 > --On Monday, April 17, 2017 01:29 -0500 Rodger Combs > wrote: >=20 >> Hello, all! >>=20 >> I've been reading a lot about IDN homoglyph attacks lately, >> and how browser handling is generally deficient in this area >> in certain edge cases. Most recently, there's been a lot of >> attention to the issue of domain labels that are entirely >> within a single script, but contain all glyphs that are >> confusable with those in another script. >=20 > Rodger, I hope you understand that is really old news, with > examples introduced into ICANN meetings by 2002. You should > also not make the mistake of assuming that UTS#39 either covers > all important cases or represents consensus in the IDNA and DNS > communities. Certainly so; it just happens to have had a bit of new attention lately = that I noticed. I wasn't aware (but am not surprised) that there's = controversy around UTS#39, though. >=20 >> Firefox and Chrome >> display the characters and allow the homoglyph attack, while >> Safari prevents the recently-discussed case by not allowing >> Cyrillic in IDN. >=20 > One of the sources of this "problem" is that Greek, Latin, and > Cyrillic are very closely related due to the derivation of the > latter two and a lot of borrowed, even if then somewhat > transfored characters, facts known to many schoolchildren. > However, their are not the only set of scripts with such > relationships and the very notion of a "script" and whether two > related writing systems use the same script or different once > can be a little subject and arbitrary, not unlike the question > of whether two groups of people speak different languages or > dialects of the same one. It is probably also worth noting > that almost every script uses a more or less vertical stroke > and/or a more or less horizontal or diagonal one, and/or some > sort of round thing as a letter or digit. So, yes, one can > solve some problems by rejecting Cyrillic and even more by > rejecting Cyrillic and Greek script or, in principle, Latin > script and either of the other two. One can then start looking > for other sets (pairs of more) or scripts and figure out which > ones are most important. But, sooner rather than later, one > doesn't have IDNs at all but a moderately small collection of > scripts that are preferred, perhaps for political reasons. Yup, aware, and that preference (which is seen in Chromium, Safari, and = others today) is what I was seeking to avoid. >=20 >=20 >> Chromium's solution is to display Punycode if >> a label is entirely composed of a hardcoded list of >> confusable-with-Latin characters. >=20 > That is the Greek-Latin-Cyrillic European bias described above. > It is probably unreasonable to compare everything with Latin and > then assume one is done. One can (and we do) have similarities > or confusion among other sets of scripts, especially those with > relatively recent common origins, as well. Yup. >=20 >> I find all of these behaviors insufficient >=20 > I hope you don't think you are going to find a single, magical, > solution because, due to both the way various scripts developed > from each other and then are used in different ways in different > languages and to issue with human perception and artistic type > styles, there is almost certainly no such solution. >=20 >> Chromium's new solution relies on its hardcoded list being >> sufficient, and one could imagine some edge case where a >> legitimate label is composed entirely of the listed characters. >> Firefox's and Chrome's current behavior is clearly >> problematic, as it allows for the attack. Safari's behavior >> completely fails users of Cyrillic, Greek, and Ethiopic >> scripts, none of which are whitelisted. >=20 > Yes. Again, the quest for magical and simple solutions is never > going to yield completely satisfactory results. Not completely, but I can hope for better! >=20 >> I've been thinking of potential solutions to this problem. In >> particular, I'd like it to protect against attacks on all >> domains (not just ASCII ones), and also protect against >> single-script confusables. I've come up with a proposal, and I >> hope to get some feedback on it to determine what complexities >> or edge cases I'm sure I'm overlooking. >>=20 >> Proposed change: >>=20 >> The ToASCII and ToUnicode algorithms remain the same, for the >> purposes of storing and displaying domain labels as strings. >> However, ToASCII is replaced with a new algorithm for the >> purposes of making DNS lookups. A new algorithm, ToDNSASCII, >> is defined, as follows: >=20 > See Will's note about IDNA2008. Note that by forbidding symbols > and everything else that is not analogous to a letter or digit, > it eliminates many cases your analysis doesn't appear to have > even gotten to yet. Ah, very nice. >=20 >> Perform steps 2 and 3 of ToASCII. >> Decompose the sequence using Unicode normalization form KD. >> Remove all combining code points from the sequence. >=20 > Especially with NFKD, your eliminated a lot of useful and > important characters. Latin script provides particular lurid > examples: with a few exceptions like "=C3=B8" (U+00F8) (and the fact > that it is an exception is actually a problem), you've > eliminated substantially all Latin-script letters that are in > any way "decorated" (diacritical marks of all flavors included > but note Asmus's second note). As Asmus says, non-starter. (I do know diacritics don't include all combining marks, but I'd gotten = tired of typing "combining code points", "character" felt incorrect, and = "marks" felt weird since CGJ doesn't have a displayed glyph, though now = that I look in more detail not-on-mobile I see the FAQ uses "combining = marks"...) I'm still interested in what cases this specific removal actually = prevents. Asmus mentioned pairs of legitimate domains differing only in = diacritics, which is about the only response here that's actually = surprised me so far. Do you know any specific examples of this case? >=20 >=20 >> Replace all instances of TR39 source-characters with their >> corresponding target-strings in the sequence. Perform steps 5 >> through 8 of ToASCII. >> This algorithm effectively produces a "folded" version of the >> string, similarly to a collation normalization. It is a lossy >> procedure, so the resulting string must not be treated as a >> "canonical" name or displayed to the user as if it were. When >> sending a label to a resolver, the ToDNSASCII algorithm is >> used instead of ToASCII. If the resolver returns NXDOMAIN, >> retry using the original ToASCII algorithm. >=20 > During the development of IDNA (both versions) the DNS folks > were very clear (for good reason, IMO) that a systems that > relied on looking up one string and, if that failed, looking up > another was a complete non-starter for both performance and DNS > design philosophy reasons. Variations on what you are > suggesting were considered and rejected for that and other > reasons. Extremely fair, and combined with the next point, an unresolvable = blocker on the entire concept as proposed. >=20 >> When registering >> domains, writing zone files, or in similar circumstances, >> perform both ToASCII and ToDNSASCII and store the results of >> both if they differ.=20 >=20 > This doesn't work either. It is a variation on the idea of > "variant" as most recently interpreted by ICANN and depends on > both names being registered to the same party. That words > better for some protocols than others, can be harder to manage > (at least for things other than web sites) than people imagine, > and we've had history of arbitrators and courts separating pairs > of names that the original registrants thought were bound > together forever. Your idea at least has the advantage over > separate others of guaranteeing that problem labels come in > pairs rather than creating combinatorial explosions at a single > subtree of the DNS. >=20 >> For all existing registered domains, >> register ToDNSASCII(ToUnicode(domain)). If this name is >> already registered, default precedence to the older >> registration, and notify the registrant of the newer domain. >=20 > Unless I misunderstand you, as soon as both strings are > registered, especially to two different parties, you create an > opportunity for exactly the attacks you are trying to prevent. > Or, if you mean "block the proposed new registration" when you > say "notify the registrant", you've blocked a lot of perfectly > reasonable names for no really good reason. Again, you don't > even need to go outside Latin script to see the problem: > Applying NFKD to "f=C3=BCr" gives U+0066 U+0075 U+0308 U+0072. > Then, if I understand your algorithm correctly, you discard the > combining diaeresis, leading to "fur" for which there appear to > be second-level registrations in a number of domains. And many > people would argue that "f=C3=BCr" and "fur" are not even > confusable, at last unless one believes that any decorated > character can be confused with the associated base one and any > other decorated character with the same base. Ah, I was unclear here. I meant that for existing registrations, a = registrar would give the folded value to the older registrant only, and = block future registrations where the folded value was already = registered. I was indeed explicitly intending for "f=C3=BCr" to be considered a = collision with an existing registration "fur" and be blocked. If this = body believes that decorated characters cannot in general be confused = with the base or other decorated variants, then yes, the "remove = combining code points" step should be removed. Thanks, --Rodger= --Apple-Mail=_4BF6B295-7F93-4F27-9978-FE6C7DA94B8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks for the detailed response; I really = appreciate the context! I know this is a complex problem, and I hope I = haven't been involuntarily implying that it seemed otherwise. I have no = delusions of my concepts approaching perfection; merely that with some = work, improvements could be made over what browsers currently = implement.

A = few specific replies inline, but here's a refreshed proposal that I = believe addresses the technical concerns you brought up:

  • Make no change to names as used in = DNS.
  • Instead, each registry maintains an internal = database of "folded" variants of domains, and refuses new domains which = "fold" to a value matching that of an existing one.

This solves = backwards-compatibility, performance, DNS design, and "variant" = management problems. Remaining concerns include (but remain distinctly = not limited to):

  • Registries would = actually have to do this.
  • If domain pairs differing = only by combining marks are indeed commonly legitimate, then the = relevant stripping would need to be removed (see bottom reply).
  • The incomplete nature and lack of consensus around = UTS#39.
  • The action to take if existing domains = collide.
  • The action to take if existing domains = became colliding after future updates to the confusables list.
  • Exceptions like U+00F8.

At this point, I think the best thing I = could do is probably grab a list of domains (.com, perhaps), write up a = script to perform this algorithm, and see what collisions come out. If = they turn out to be predominantly legitimate, then there's probably no = point pursuing this further. If there are very few, or the bulk appear = to be illegitimate, then this might be worth hashing out in more detail. = Does that seem reasonable?

On Apr 17, 2017, at 22:57, John = C Klensin <klensin@jck.com> wrote:



--On Monday, April 17, 2017 01:29 -0500 Rodger = Combs
<rodger.combs@gmail.com> wrote:

Hello, all!

I've been reading a lot about IDN homoglyph = attacks lately,
and how browser handling is generally = deficient in this area
in certain edge cases. Most = recently, there's been a lot of
attention to the issue of = domain labels that are entirely
within a single script, = but contain all glyphs that are
confusable with those in = another script.

Rodger, I hope = you understand that is really old news, with
examples = introduced into ICANN meetings by 2002.  You should
also not make the mistake of assuming that UTS#39 either = covers
all important cases or represents consensus in the = IDNA and DNS
communities.

Certainly so; it just happens to have had a bit of = new attention lately that I noticed. I wasn't aware (but am not = surprised) that there's controversy around UTS#39, though.


Firefox = and Chrome
display the characters and allow the homoglyph = attack, while
Safari prevents the recently-discussed case = by not allowing
Cyrillic in IDN.

One of the sources of this = "problem" is that Greek, Latin, and
Cyrillic are very = closely related due to the derivation of the
latter two = and a lot of borrowed, even if then somewhat
transfored = characters, facts known to many = schoolchildren.
However, their are not the = only set of scripts with such
relationships and the very = notion of a "script" and whether two
related writing = systems use the same script or different once
can be a = little subject and arbitrary, not unlike the question
of = whether two groups of people speak different languages or
dialects of the same one.   It is probably also = worth noting
that almost every script uses a more or less = vertical stroke
and/or a more or less horizontal or = diagonal one, and/or some
sort of round thing as a letter = or digit.   So, yes, one can
solve some problems = by rejecting Cyrillic and even more by
rejecting Cyrillic = and Greek script or, in principle, Latin
script and either = of the other two.  One can then start looking
for = other sets (pairs of more) or scripts and figure out which
ones are most important.  But, sooner rather than later, = one
doesn't have IDNs at all but a moderately small = collection of
scripts that are preferred, perhaps for = political reasons.

Yup, aware, and that preference (which is seen in = Chromium, Safari, and others today) is what I was seeking to = avoid.



Chromium's solution is to display Punycode = if
a label is entirely composed of a hardcoded list of
confusable-with-Latin characters.

That is the Greek-Latin-Cyrillic = European bias described above.
It is probably unreasonable = to compare everything with Latin and
then assume one is = done.   One can (and we do) have similarities
or = confusion among other sets of scripts, especially those with
relatively recent common origins, as well.

Yup.


I find all of these behaviors insufficient

I hope you don't think you are = going to find a single, magical,
solution because, due to = both the way various scripts developed
from each other and = then are used in different ways in different
languages and = to issue with human perception and artistic type
styles, = there is almost certainly no such = solution.

Chromium's new solution relies on its hardcoded = list being
sufficient, and one could imagine some edge = case where a
legitimate label is composed entirely of the = listed characters.
Firefox's and Chrome's current behavior = is clearly
problematic, as it allows for the attack. = Safari's behavior
completely fails users of Cyrillic, = Greek, and Ethiopic
scripts, none of which are = whitelisted.

Yes.  Again, = the quest for magical and simple solutions is never
going = to yield completely satisfactory = results.

Not = completely, but I can hope for better!


I've been thinking of = potential solutions to this problem. In
particular, I'd = like it to protect against attacks on all
domains (not = just ASCII ones), and also protect against
single-script = confusables. I've come up with a proposal, and I
hope to = get some feedback on it to determine what complexities
or = edge cases I'm sure I'm overlooking.

Proposed= change:

The ToASCII and ToUnicode = algorithms remain the same, for the
purposes of storing = and displaying domain labels as strings.
However, ToASCII = is replaced with a new algorithm for the
purposes of = making DNS lookups. A new algorithm, ToDNSASCII,
is = defined, as follows:

See = Will's note about IDNA2008.  Note that by forbidding symbols
and everything else that is not analogous to a letter or = digit,
it eliminates many cases your analysis doesn't = appear to have
even gotten to yet.

Ah, = very nice.


Perform steps 2 and 3 of ToASCII.
Decompose the = sequence using Unicode normalization form KD.
Remove all = combining code points from the sequence.

Especially with NFKD, your eliminated a lot of useful and
important characters.  Latin script provides particular = lurid
examples: with a few exceptions like "=C3=B8" = (U+00F8) (and the fact
that it is an exception is actually = a problem), you've
eliminated substantially all = Latin-script letters that are in
any way "decorated" = (diacritical marks of all flavors included
but note = Asmus's second note).  As Asmus says, non-starter.

(I do = know diacritics don't include all combining marks, but I'd gotten tired = of typing "combining code points", "character" felt incorrect, and = "marks" felt weird since CGJ doesn't have a displayed glyph, though now = that I look in more detail not-on-mobile I see the FAQ uses "combining = marks"...)
I'm still interested in what cases this specific = removal actually prevents. Asmus mentioned pairs of legitimate domains = differing only in diacritics, which is about the only response here = that's actually surprised me so far. Do you know any specific examples = of this case?



Replace all instances of = TR39 source-characters with their
corresponding = target-strings in the sequence. Perform steps 5
through 8 = of ToASCII.
This algorithm effectively produces a "folded" = version of the
string, similarly to a collation = normalization. It is a lossy
procedure, so the resulting = string must not be treated as a
"canonical" name or = displayed to the user as if it were. When
sending a label = to a resolver, the ToDNSASCII algorithm is
used instead of = ToASCII. If the resolver returns NXDOMAIN,
retry using the = original ToASCII algorithm.

During the development of IDNA (both versions) the DNS = folks
were very clear (for good reason, IMO) that a = systems that
relied on looking up one string and, if that = failed, looking up
another was a complete non-starter for = both performance and DNS
design philosophy reasons. =   Variations on what you are
suggesting were = considered and rejected for that and other
reasons.

Extremely fair, and combined with the next point, = an unresolvable blocker on the entire concept as proposed.


When = registering
domains, writing zone files, or in similar = circumstances,
perform both ToASCII and ToDNSASCII and = store the results of
both if they differ.

This doesn't work either. =  It is a variation on the idea of
"variant" as most = recently interpreted by ICANN and depends on
both names = being registered to the same party.  That words
better = for some protocols than others, can be harder to manage
(at = least for things other than web sites) than people imagine,
and we've had history of arbitrators and courts separating = pairs
of names that the original registrants thought were = bound
together forever.  Your idea at least has the = advantage over
separate others of guaranteeing that = problem labels come in
pairs rather than creating = combinatorial explosions at a single
subtree of the = DNS.

For= all existing registered domains,
register = ToDNSASCII(ToUnicode(domain)). If this name is
already = registered, default precedence to the older
registration, = and notify the registrant of the newer domain.

Unless I misunderstand you, as = soon as both strings are
registered, especially to two = different parties, you create an
opportunity for exactly = the attacks you are trying to prevent.
Or, if you mean = "block the proposed new registration" when you
say "notify = the registrant", you've blocked a lot of perfectly
reasonable names for no really good reason.  Again, you = don't
even need to go outside Latin script to see the = problem:
Applying NFKD to "f=C3=BCr" gives U+0066 U+0075 = U+0308 U+0072.
Then, if I understand your algorithm = correctly, you discard the
combining diaeresis, leading to = "fur" for which there appear to
be second-level = registrations in a number of domains.  And many
people = would argue that "f=C3=BCr" and "fur" are not even
confusable, at last unless one believes that any decorated
character can be confused with the associated base one and = any
other decorated character with the same base.

Ah, I = was unclear here. I meant that for existing registrations, a registrar = would give the folded value to the older registrant only, and block = future registrations where the folded value was already = registered.
I was indeed explicitly intending for "f=C3=BCr" = to be considered a collision with an existing registration "fur" and be = blocked. If this body believes that decorated characters cannot in = general be confused with the base or other decorated variants, then yes, = the "remove combining code points" step should be = removed.

Thanks,
--Rodger
= --Apple-Mail=_4BF6B295-7F93-4F27-9978-FE6C7DA94B8A-- From nobody Mon Apr 17 23:56:44 2017 Return-Path: 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 65FE0131555 for ; Mon, 17 Apr 2017 23:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 5Q0zAA7FoEnL for ; Mon, 17 Apr 2017 23:56:41 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF522128D69 for ; Mon, 17 Apr 2017 23:56:40 -0700 (PDT) Received: from [77.72.226.187] (unknown [IPv6:2a01:3f0:1:0:c037:7360:3181:2488]) by mail.frobbit.se (Postfix) with ESMTPSA id 0571522FD0; Tue, 18 Apr 2017 08:56:38 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Rodger Combs" Cc: "Asmus Freytag" , idna-update@ietf.org Date: Tue, 18 Apr 2017 08:56:44 +0200 Message-ID: <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> In-Reply-To: <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_EAB0C7D7-35B9-49A3-8734-14A2D82F2A8E_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 06:56:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_EAB0C7D7-35B9-49A3-8734-14A2D82F2A8E_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 18 Apr 2017, at 3:48, Rodger Combs wrote: > That step is more or less separable from the rest of the concept, but I= 'm curious why you say that. Is it common for legitimate domains to diffe= r only by combining code points after NKFD? Note that this would not prev= ent _display_ of diacritics. There are many scripts that require use of combining characters for a cor= rect display of the script. So this is as Asmus wrote a non-starter. The evaluation of classes of code points have already been dealt with in = IDNA2008. Patrik --=_MailMate_EAB0C7D7-35B9-49A3-8734-14A2D82F2A8E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlj1uKwACgkQrMabGguI182E+gCfV3jK+rLeuGHpWXB46lMYZx0J rcoAoIKxlsRL7hTWEe11Xjw4aKRchDEu =UIS+ -----END PGP SIGNATURE----- --=_MailMate_EAB0C7D7-35B9-49A3-8734-14A2D82F2A8E_=-- From nobody Tue Apr 18 00:09:05 2017 Return-Path: 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 905B5128D69 for ; Tue, 18 Apr 2017 00:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 aaNGYEZoweXZ for ; Tue, 18 Apr 2017 00:09:02 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE010127419 for ; Tue, 18 Apr 2017 00:09:01 -0700 (PDT) Received: from [169.254.93.2] (dyn-fg187.sth.netnod.se [77.72.226.187]) by mail.frobbit.se (Postfix) with ESMTPSA id 25D9523C77; Tue, 18 Apr 2017 09:08:59 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Rodger Combs" Cc: "John C Klensin" , idna-update@ietf.org Date: Tue, 18 Apr 2017 09:09:05 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_31F60AE3-CD24-46A5-BED6-8F56A0D2980E_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:09:04 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_31F60AE3-CD24-46A5-BED6-8F56A0D2980E_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable There are many initiatives that have started, and failed, and restarted, = and it is important when trying to "do something" to note what has been g= oing on, and as John and Asmus writes between the lines not extrapolate f= rom the script(s) you know to other scripts as (also as John explains) no= t only are the scripts different. They are also added in slightly differe= nt ways to the Unicode Character Set. To try to summarize we have a number of issues here: 1. People seems to use either IDNA2003, IDNA2008 or some home-brew combin= ation of IDNA2003, IDNA2008 and UTS#46. It is quite important that we all= agree that IDNA2008 is what defines what characters can be used in domai= n names. 2. For mapping, case folding etc, we know already from IDNA2003 that this= is locale and otherwise context dependent. Some work have been done in I= ETF to look at this, UTS#46 includes some suggested mappings and normaliz= ations, but also too much other cruft that one simply can not allow if on= e follows [1] above, use IDNA2008. 3. Policies must be developed by the registries and also browser and othe= rwise software so that surprises are minimized. This must of course take = [1] and [2] into account, but for example the fact that registries have a= llowed all of IDNA2008 PVALID characters for registration and no addition= al rules like "all code points [in the same label or whole domain name] m= ust be the same script" is what in this case have created some of the pro= blem. At least such rules might have made the situation easier. The LGR p= rocess in ICANN (we can have different views on efficient, effective and = correct it has been) was created as the intention to "do the right thing"= script by script. I am extremely happy to "see a new face" being interested in characters a= nd IDN because to be honest, the number of individuals that have been wor= king on these issues have been very limited. And we need to be more peopl= e that think, HARD, on these problems. And the problems are serious. Patrik --=_MailMate_31F60AE3-CD24-46A5-BED6-8F56A0D2980E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlj1u5EACgkQrMabGguI181tuACeJsUHwxoA1WNv/AdtGXu8MZ1r a2IAn1E7Texz29Gv0+li1gtfcb1/aUiN =Bnq0 -----END PGP SIGNATURE----- --=_MailMate_31F60AE3-CD24-46A5-BED6-8F56A0D2980E_=-- From nobody Tue Apr 18 00:59:55 2017 Return-Path: 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 68E8313177C for ; Tue, 18 Apr 2017 00:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 CfbDcmrVqHAK for ; Tue, 18 Apr 2017 00:59:52 -0700 (PDT) Received: from bsa2.jck.com (ns.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 38D141243F6 for ; Tue, 18 Apr 2017 00:59:52 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0O39-000B4R-Im; Tue, 18 Apr 2017 03:59:47 -0400 Date: Tue, 18 Apr 2017 03:59:41 -0400 From: John C Klensin To: Rodger Combs , Asmus Freytag cc: idna-update@ietf.org Message-ID: <969C4B4EF625F804BFAD622F@PSB> In-Reply-To: <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> 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.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:59:53 -0000 --On Monday, April 17, 2017 20:48 -0500 Rodger Combs wrote: >> * Remove all combining code points from the sequence. >> >> is itself a non-starter. > > That step is more or less separable from the rest of the > concept, but I'm curious why you say that. Is it common for > legitimate domains to differ only by combining code points > after NKFD? Yes. > Note that this would not prevent _display_ of > diacritics. One of the things that drove the IDNA2008 work was the discovery, reinforced by considerable experience, that not having a reversible mapping between what we now call U-label and A-label forms caused all sort of problems and ambiguities. Unless I misunderstand your proposal, you are going to reintroduce that problem. Do try to understand the IDNA2008 specs. While you are at it, I suggest reading RFC 4690. best, john From nobody Tue Apr 18 01:03:49 2017 Return-Path: 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 06B861317F8 for ; Tue, 18 Apr 2017 01:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-org.20150623.gappssmtp.com 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 rdrceVLfRvRJ for ; Tue, 18 Apr 2017 01:03:43 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1741317BC for ; Tue, 18 Apr 2017 01:03:43 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id l28so96472909wre.0 for ; Tue, 18 Apr 2017 01:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zkThmU0rlZ3iXer/h0QtakfuOuKeSrs7KQ/sSGwyAfo=; b=qM2eXWGqdfvp8faUdKMfnW59b5ahmJ54LOII2GG6sRN6Z381HpZKETxYAaLHsF5/yw nuqOKoJ+j55O2GC4gt5ti4cxkowmCSGcHYQn9q6t9T03Ade8XpKkqXBQLW55qNwTYW48 mKx1dSx9xKhC6FwyKPQ5b76D2BBZi6YSiMrm84cgdDPrEi9CeHIvGlB1hnmxsjAfJYLe Jc6Sr+24f3TyD7tJ1vy2PuO8aCKGIddC/DEFNB3Wb7BNwKN85xm095AHMz6uT9AR1PiH UYRpNkdb7ujmBqG3zSKgUZSQsXX1gSGeICfm7nD4pQPgcfW2EO1ayGqOmZSq+Rz43c+C OK3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zkThmU0rlZ3iXer/h0QtakfuOuKeSrs7KQ/sSGwyAfo=; b=HW2tq0SXrjyMuouPhl3YDwUq17WAECIF1DvIkBK2ECnBquZWmUrEXYUZiwnrPRuIh4 b7vP7qLM4WzZ0c7rOUHP4AHGAXYAJTTkai3MXQmH4PeTlIpnM4NbI34XAedcMmyg4NkF GseMLka+aVEinlx96aCp6qNkxWnH6e1u6MwxzHkAkyXvbOzKJ0az2ucv0w50L6cphgot c0pvSoVR4B1wn+TTq/V0ox3D43X0CNfdE4YauwbsYSJg9oC5jx31p6bwtYm29cur/xHx CF27FwMvCnwq5EfwFsEBafj/ta9ePhot7YxqYenILTVMXEAw0cZuG0rWq8ftk00HB/oH GVXw== X-Gm-Message-State: AN3rC/7UTPzeJiJe6LzaTEPjafNpmT12ql15rW/mVkABkE0JaryNuB6V gFPYk8vliWviya/Cb1kIrg== X-Received: by 10.223.160.69 with SMTP id l5mr23742581wrl.49.1492502621578; Tue, 18 Apr 2017 01:03:41 -0700 (PDT) Received: from [192.168.0.105] (cpc116904-shep14-2-0-cust913.8-3.cable.virginm.net. [80.192.227.146]) by smtp.gmail.com with ESMTPSA id 92sm17572537wra.18.2017.04.18.01.03.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 01:03:40 -0700 (PDT) To: Rodger Combs , John C Klensin References: Cc: idna-update@ietf.org From: Gervase Markham Message-ID: Date: Tue, 18 Apr 2017 09:03:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:03:45 -0000 On 18/04/17 06:00, Rodger Combs wrote: > * Make no change to names as used in DNS. > * Instead, each registry maintains an internal database of "folded" > variants of domains, and refuses new domains which "fold" to a value > matching that of an existing one. That is the correct solution, and is what Mozilla is arguing for (with "fold" being defined by the Unicode confusables list). Now your only problem is persuading registries to implement it. Gerv From nobody Tue Apr 18 01:17:09 2017 Return-Path: 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 7ECE31317BC for ; Tue, 18 Apr 2017 01:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oTnNm3e2XbV1 for ; Tue, 18 Apr 2017 01:17:05 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30BF126DEE for ; Tue, 18 Apr 2017 01:17:04 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id x86so31523557ioe.3 for ; Tue, 18 Apr 2017 01:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HhF5Kr5e9RktfM+AGtwCr0fVj3lF2GYZBqidpL3ypOI=; b=QCrkU8FmuOCFGDdLjUTGpOe/bqta9/AMMK5MvBOo0QtUl0pmDGedhCfM+/2XUBt3y8 kgqjbUIJUMsJOWCl/QBUUkEv3hdQdbFUwuuUvX0aok+umCsiywL6W40mRB7SES2VzScL x1IMAXYWHaiiqA0BJ+qHXCJbbDXJccKPLHHpYKrukd3aSBKS3h2SHfJ3AvCf8164Bu/k iblNALNS5aw7vOd1haYo//oEOoK7cb4olk61+9pGa+LkXbwj0Y5a5kBzDuaC8xCl5h7P nUUfNoHjb4YrPIzpun5cuDGi725RsMgnQAX204ULDI2es/J+zcHOqg3BTehhCxCfg3iq ZGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HhF5Kr5e9RktfM+AGtwCr0fVj3lF2GYZBqidpL3ypOI=; b=W0UWLSsdgfiFdpMkh7SJ3QXmrqcq5sXbjKZ3R/kUOX/7lII09q1+Fw/whMLlirqlAU uPVf7/qjVSnWnV4RJxdY3DrYgOMX4PqPify4ak1Fj58aKeRZXmGDVh8nhH2J+Uvrdlec iTSEDAlDVZQFAEMv5RbY88NShePh65kXJWlsj3/A9qpBnzzYRSDQTy8Al1I24D+pRNL/ ekg2w9q2ZKz89cUOwPadr0e85bOauKo1Mvc1WQnzh7+bFTmbiYV2NCMlSPamlxicN69I 6NcV2wSOBHBBrA4GYvL1uIEPohZNvLZ4lmQdgYX5r9+3tBtf+X1ZIeh4XpCm3ZS+0cwV Pb2g== X-Gm-Message-State: AN3rC/6rlRMvT1P+rIYMm4arnsjV1PEZ93BWw4/G/av3Ftvyj5m4LlJL DP45qpF/OBWDsg== X-Received: by 10.36.52.200 with SMTP id z191mr13983349itz.122.1492503423908; Tue, 18 Apr 2017 01:17:03 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:3c9c:1d39:5c75:4294? ([2601:243:504:643:3c9c:1d39:5c75:4294]) by smtp.gmail.com with ESMTPSA id j2sm4595402itd.0.2017.04.18.01.17.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 01:17:03 -0700 (PDT) From: Rodger Combs Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_89C67C03-5B58-490B-9AB9-EE1A3F24ED57" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Apr 2017 03:17:02 -0500 In-Reply-To: <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> Cc: Asmus Freytag , idna-update@ietf.org To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:17:07 -0000 --Apple-Mail=_89C67C03-5B58-490B-9AB9-EE1A3F24ED57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 18, 2017, at 01:56, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > On 18 Apr 2017, at 3:48, Rodger Combs wrote: >=20 >> That step is more or less separable from the rest of the concept, but = I'm curious why you say that. Is it common for legitimate domains to = differ only by combining code points after NKFD? Note that this would = not prevent _display_ of diacritics. >=20 > There are many scripts that require use of combining characters for a = correct display of the script. I completely understand this, but it's besides the point. What I'm = suggesting at this point is that registries effectively ban new = registrations that differ from existing registrations only in combining = marks, _not_ that combining marks themselves not be allowed in actual = domains, and I never suggested that they not be _displayed_. The only case this would break would be non-malicious registrations that = differ only by combining marks. There's a valid debate to be had over = whether or not that's a useful thing to restrict against, but let's not = confuse the issue being discussed there. I'm looking through an all-zones dump for collisions that differ by = combining marks only. I can't hope to read through all of these myself, = but so far I've run into a couple common classes of collision: The same registrant setting up their base domain and one or more = decorated forms. My original proposal would've addressed this use-case, = but even in the new one, this is easily addressed: allow colliding = registrations when both are by the same registrant. See v=C3=ADsa.com = , coffr=C3=A8o.biz = . Deliberate homograph attacks on popular domains with diacritics added. = This seems to frequently use =C3=AD and =C3=AC, as they look very = similar to the root glyph (i) without close inspection. Most of these that I've seen are just parked domains. See wikip=C3=A9dia.o= rg , doublecl=C3=ACck.net = , doublecl=C3=ADck.net = , p=C3=ADzza.com = , t=C3=A9sla.com , = k=C3=ADckstarter.com , w=C3=ADne.com = . A few have been weird, though. See pok=C3=A9mongo.com = , linked=C3=ADn.com = , and p=C3=A1ypal.com = (which looks like it might seriously be a = phishing site of some sort). If this email gets flagged as spam for all those links, I'm gonna laugh. >=20 > So this is as Asmus wrote a non-starter. >=20 > The evaluation of classes of code points have already been dealt with = in IDNA2008. >=20 > Patrik --Apple-Mail=_89C67C03-5B58-490B-9AB9-EE1A3F24ED57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 18, 2017, at 01:56, Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se> = wrote:

On 18 Apr 2017, at 3:48, Rodger Combs wrote:

That step is more or = less separable from the rest of the concept, but I'm curious why you say = that. Is it common for legitimate domains to differ only by combining = code points after NKFD? Note that this would not prevent _display_ of = diacritics.

There are many = scripts that require use of combining characters for a correct display = of the script.

I completely understand this, but it's besides the = point. What I'm suggesting at this point is that registries effectively = ban new registrations that differ from existing registrations only in = combining marks, _not_ that combining marks themselves not be allowed in = actual domains, and I never suggested that they not be = _displayed_.
The only case this would break would be = non-malicious registrations that differ only by combining marks. There's = a valid debate to be had over whether or not that's a useful thing to = restrict against, but let's not confuse the issue being discussed = there.

I'm looking through an = all-zones dump for collisions that differ by combining marks only. I = can't hope to read through all of these myself, but so far I've run into = a couple common classes of collision:


If this email gets flagged as spam for all those = links, I'm gonna laugh.


So this is as = Asmus wrote a non-starter.

The evaluation = of classes of code points have already been dealt with in IDNA2008.

  Patrik

= --Apple-Mail=_89C67C03-5B58-490B-9AB9-EE1A3F24ED57-- From nobody Tue Apr 18 01:51:05 2017 Return-Path: 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 22833131834 for ; Tue, 18 Apr 2017 01:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 YjbvtV5H-e6v for ; Tue, 18 Apr 2017 01:51:01 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0101.outbound.protection.outlook.com [104.47.92.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864FF131832 for ; Tue, 18 Apr 2017 01:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uPNTUb302yZmZ2pJxgDxAfzUnntyzZYCfO12dteAXNw=; b=AOC66mZvB9T1Ht5iXiKd6fSGqOx4KW7TRszXj4KjgSeHbnkg7H+bG+KWS7YGUzsi3fvkRo7ebVQ+Jsvv1TFNqfliLtG07xftlvBA01ar6OewR29P9DpUR/xusdlBJCdrMsWVpOQNvEbqxNhWi1luDw3O2TcAxbbXqTC4b1XFM0s= Authentication-Results: ix.netcom.com; dkim=none (message not signed) header.d=none;ix.netcom.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0655.jpnprd01.prod.outlook.com (10.168.43.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Tue, 18 Apr 2017 08:50:53 +0000 To: Rodger Combs , =?UTF-8?Q?Patrik_F=c3=a4ltstr?= =?UTF-8?B?w7Zt?= References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> CC: , Asmus Freytag From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <4f041d48-b99f-2cc9-f1a2-c93781663743@it.aoyama.ac.jp> Date: Tue, 18 Apr 2017 17:50:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OSXPR01CA0011.jpnprd01.prod.outlook.com (10.167.143.162) To TYXPR01MB0655.jpnprd01.prod.outlook.com (10.168.43.142) X-MS-Office365-Filtering-Correlation-Id: ab709506-7351-44d7-1def-08d4863805bc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:TYXPR01MB0655; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0655; 3:Kpque0DlPT3kE41db2yhQzwflRRMMrWPv68l3bRbEF4YPOaEzmld0dO90+C7RiwElAUAKJYy6OPGhra0DAmLLxzYHhWaXF4rUB21MhzyTF+QpBVNWRFwyoHfak5GQjmBTkn2J8O9pou1X+PAInKjMlc2Wgj1Y9WF+fHXnWfwua6eqMrB24WEdW+9pBhGV0uiF6NAA83WWLEMoDdXM+2bOb2etET2amGv76VimcNmfxeJuISSylK8Pn944sS71qwbtlzD6C8VvP004fHZY3qoDsXOB1FkDYVC6jJKboK0TZ0atS6vsWW4qTuk0JXjROwdqKSlkvUWw3VIsGytYd7Wpg==; 25:fDKrSJ7ynM9uRws4z+R/6fwDR46T1hxjGTCh6TLfI1fXjPwthU1HSoxLLwiBgfc+WeQObkNn0Wl7DxBZp1BJlJUq2qCMqXHDZ2F0NZMKEYqw5FWKhFJPouG8VwxxTWMVUyPRuaAb9ddNEHFvf5VS8H3y2s1QLYtX/nEg/U+QTv/pkgecAXKxEUKie0R6Dw9upntSzEaRup1K2jbUvdlDxVemUZuN5WxeSDbrMJnAzsj4PsmAD6s9JT9BCdId80fgkQFAzB2Pv2P34wdBmHAsykPIvscL5upNqbVPtZjB830bOzAoVd1ddLbHaGmwjnnsRD5wY18h1ts5a7r7VPs6ENpDVXSet+XS1Qc/ivB32+V+ZyNUMNZYL+Q/VYCvXfz0n0+Uoe/LjY7GUEOtZNiaqlfl3+gpRwG0yfEiWTtHWdmrk08cAL22jyp12hT2ANPg7dzFU0GvhRDmKYvUsM+JsQ== X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0655; 31:gYnamg6QtvUvk2tG/qHNX+H/Y/ba3gB6OzTRyuwd5JOZN4qYjLm09mD+PrdcRpqibjmP/qtABb/prOL7mfLKbmsCc8IJ+cfgTQqSzpCCNdQIIxMUbffwV1toeJwld7Ew7BTV2MFYXywx5RQkpGR/PcRzyt5hoi4C6mETlfYcBJambPYkCbF763s4M5D9HCaoUKumcv50aKXo8USmYpYItucqu8msZtoM9cj7T0HqSoigpa2DZuuxAf0FSv4UEbrV7T4bwifdXkSwZNs/NkU0Bg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:TYXPR01MB0655; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0655; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0655; 4:XMs3gTB9aEf4qMDfGyg0W6EXHxXPP5OKXU0qNR3VmoZTc9A+tE8njFEW9aJ5c7gJg8HcavOvn8IgS6VWIBIF1zFKCwiMhyqUJELpbR2dZFq8SYug8pEr+E68pMOU4iv/OwluhaQlLi0+7HVwo8GO33fw0VE8E49ggD5OKh03nr+Ger+YSq+oqN4lJ5di9oryOI9Ntz3ZiXQ1bwynxNHKZJDhqYo5ZXMYMKPck/zeQU4BK4N/8xc+22lyRIyCeT+cRnVghyaad50reEaIaEjScyQ8rrWFC2JIvosL1cR/akn3Nr6s/g8Xfxo3KXrjjTeYYvZpk2004p3r3CnaLCOj4ZNeL5XmBoZF70nvQ5M+U5h9x2Anv3K4NkTzjWM4O3KKFkUHUYsjH+k9ctyJS0DQNhl+CPWhQB0KpxKDJPdorWh1NaRKh6/OZhPSzf98xpw+6DKbQT8bp7xpiA9L/8bv/Wy+wp53patH7vvS2iiMAuZ6Q1S49Bhz+Mi8z0uRUwYh1RKyggfIHxjKXySyPhiLpEqRATV0oA4d9HNy8ej6au9kKdwJEyw27SxpeCUTZgAlk9kVxBG6JnejkRk/9WHU/O+DFPNhYFwd0nqNk0Rn+l5Pwm2tXMNQQw/SOkXsxH24/LVJ/f+RVcZaToXWc3QV+sV83Cjq0xCGdPLdA0XQ9XvwTkqNzFBhHHTjwr6C4muuwbNKrGPgCQXNiF4xyKJuVOHAV+IQCo5BtXM9zMu3z+Y= X-Forefront-PRVS: 028166BF91 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39410400002)(39450400003)(24454002)(23676002)(47776003)(33646002)(25786009)(93886004)(76176999)(229853002)(50986999)(54356999)(8666007)(42882006)(90366009)(6486002)(2870700001)(31686004)(2950100002)(54906002)(6246003)(42186005)(4001350100001)(38730400002)(4326008)(53546009)(65806001)(66066001)(65956001)(189998001)(53936002)(31696002)(83506001)(3846002)(5660300001)(305945005)(7736002)(74482002)(86362001)(6116002)(50466002)(81166006)(8676002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0655; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwNjU1OzIzOkFkZ25RVWo5UjhSQkFNanU3aUJQWHpDZDZQ?= =?utf-8?B?OG80MEUxMVd2YnU3TXE2dzcxSlhPemdhQm9TUFhRUXRnOE1uaVJOSVptWFFo?= =?utf-8?B?emxialJRNnhuU2VuTktQeEZ4SUUyUFFmQ1E5Z0NNSUlJVWdpQUxValc2MVZC?= =?utf-8?B?K1pSRlJEeHQ4dWc5eTQrK2hpazM4ZUFlMGc2QjFnaHMvYlhQd3pqMm5GbWtt?= =?utf-8?B?MjV1SjR0V3BldGpGNWlFbGM5Y0krUE4zNnJpMkkwU3o3b3BiVUx5VXlTUExm?= =?utf-8?B?amc1d3ZTa2dqeVFFVnlocmZEcDFmTXRVWmFnTGgxcDNQdE5HSnhUYjRYUkRX?= =?utf-8?B?RGliUm5QQ0hjbHp2OEFJUlJNamFuN3d6SmlLRVBMTHZqN2VXa2x5NEZDTUlN?= =?utf-8?B?bHJwZ1d0L05NdURMYXFob3U4empVd3FCMHdhUHVzVUowRXozbUYvSzlZczBh?= =?utf-8?B?M2pxcWMzZ1dYYzk2LzNLelpDSFNUaTJsTFdxd2tySlByODZ0Y0JVZWxXRExa?= =?utf-8?B?TSt4UmRHUGV4MG9rZkxWOHI2T2M3Z1h3RnRtcXR6bHpObXk3dTlzR2JmV3hG?= =?utf-8?B?UkZ6cXhlNjM1QWxZdkNWYXpxb1BiYTZwdnZtSzNYOStLN2tUWGcwcERtK3ha?= =?utf-8?B?V1psM1VpMWNwQ0FyZTkzdDVzRGdsYWkxandYTksrOS9DUWw4ZU9xbGFtVHNB?= =?utf-8?B?c0FGVlNSRHZycnhWak5IS1ByWmVzMXNuL3V0d3JaT3ZhbXNVaWtKNDh2T1gr?= =?utf-8?B?NkVGdlovMkttRVRyanBUTldyeGVuSEw2b29oUnkvYXh3ejdUbFRRNnRRQUhl?= =?utf-8?B?dHN1dWs1eWpiR1dkYlFQd2FWSTJaTkVYTDBXNUJYcU15eHVEbjNvREZOMVE0?= =?utf-8?B?S2pyS1Yrd3BvZkZtZ0lrcGlTV1FsbjkwOURKc3E5RmVkOTZCeGZKajE2U0Vk?= =?utf-8?B?Rm9LNHYxc3VQQ1BzQ1BUdlpGc0hIbEZFd1E1SDlhWE1RNkRQQmNpWFh3akdo?= =?utf-8?B?RjBkVklWWVRYR1k3V1V3L0dSQ0RyNWdZYkxoam9Lc3I5ZXhoZTBCN2xHemZw?= =?utf-8?B?aTVKbmluS1JDRGlleTA5djJicFJFTDZKd2RYcjI0U242Y0dkbDQyK1BwKzM5?= =?utf-8?B?L0hqK0EzeWduTGZ6czZ0cDBsb1doZlZkSkQvamkwU1VlWjJGN2ExYnNscDBp?= =?utf-8?B?MXBkUm0zeS9lN3ZCbS9CcjlzNStzcXcxcXhWL09XQmcwUFhqM0s2cHJWa0dN?= =?utf-8?B?YlpMaHVvRXNSNzExQWxwSXpibWF5MExMWXRzSmg2UzBJUkJSd3RxMjJjWG5C?= =?utf-8?B?anBRN2dDVHNOMk5QWUhPRkNoQ0x2eVFCdldSSmlhYmZrc3cyOGxWYjJLcU44?= =?utf-8?B?TUhKekcyN3o4K0hzTmRFMDZvcUFpY01sYUtDak95enVYSWJGR2VTc1RzUFJR?= =?utf-8?B?V0licStrL0F5dXNVMC95MnB3RUpBU1FKbEhJbEhyNVpvM0NjSER0THBCSFBI?= =?utf-8?B?RlRaMFowTUcyeWJTRXJBSnhGTEFkYTBZYzNnTGVVWEYrN2xaSlhxdmRjYTJ4?= =?utf-8?B?YzY0ZHA4RXVPcW9HT0hubU9XSUpMQVJZNzlmaUlJRGxSWm0vM1o3OGwwY0kv?= =?utf-8?Q?dynFrx5OTS7VJwvKdSQT?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0655; 6:THUVHaLg9+Kqu/kd7scNswKCevwdG0zZHUDvgJvFBUHuB1cCcuNYtPto020E1LknBsnhZClwEujKKdzoIJGL5M2cNPpU37wCDeB9sPFIsP7WXpzGw0G8H7n94pFYSfe4jtxOvn4GgzDkWRbsvJPqaGjZELXyBmcEhqVAACWzgj68aNEhQemwpH4Ng9zFDfalPJL99dWbZ+RJwAiSzJDQVIDgA3Q7NHKo/9Z2lrqh59TIfTc2KeN6dKnV8iJ8iZyAYsTu3ZYAm6fT8JBOL7Z3TvdFaoRfREO/eQ/0vTYCxist8iKin9we1U2pZkfj/Oa3XBPDIK3u4BilExgTJB5nwK3gZlNYPFuGTvBPLK7eokqCEhvBynsmyaIMAc9nAxyF/4vtzXFFVIWjomva2y/TLGxw6QK1q3JGpdxF5kuh8/mHEbmwrnSqellHGGw2ftZh7Jc65mcAX5q/UOUTLRshmA==; 5:CkDZ1+O096GVgv7560NMhM6wdrhD0HtsJGP13oBhTcSn1UDpUCxVAleZKYpHFvTcff3Tx9JK39x+nbv9hZtbTKpGTNZyAk6YuwYtChpBK3IL7P+jxAYacCG8/VVDVLBjQLVOXhBn1HvZN14UsH9Q8A==; 24:Q98GcaYFkXAPei9tZrn8RhBKzjdn3Omz6jwgGW3AyP3IH9v6IMsJdDVa7ss69+ufWWFKvPibCUdJjRAwaYtwFWaLuV1sff5s6O7h3InYNTk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0655; 7:FTTKxdz/xe/pPKXBWmynoR/ToTHWRqFYg2qGEaAFTvncCkY9lFv3MoqIyNNPm1p/2+jDLT8743WN37imKh0Xj11+iYC41E9W/+/e6oHHOvlhGDEtOJPwGuWtDOTMWkpVsKhu1u9dJoNqHAHl0+GG6ctl1wAck2rkYD4/6wNdR/JU1D/GF812Bcz3muXi1fhxivCzfJ/MXuZiPTAJLHEN82fVndXoHbAwPlNPEdw4dYrllj0ODMT+HKg1BPXsUAeX3/yL33o3GuxlaKxENeePhwgP7KQX0d6Xt0R1hMrxnSo9VRc1+ek1IOa8V1Jcc4NzysZ4ypIKpHteDY3pYOGT/Q== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2017 08:50:53.6525 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0655 Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:51:04 -0000 On 2017/04/18 17:17, Rodger Combs wrote: > The only case this would break would be non-malicious registrations that differ only by combining marks. There's a valid debate to be had over whether or not that's a useful thing to restrict against, but let's not confuse the issue being discussed there. I don't know of any actual registered examples, but in the languages that use accents/diacritics/combining marks, these are usually there to make a distinction. The distinction can be related to grammar (e.g. German "Buch" (book) vs. "Bücher" (books), or it may distinguish totally unrelated things (e.g. German "Durst" (thirst) vs. "Dürst" (a family name)). How much is grammar and how much is unrelated stuff will depend on the language. As far as I understand, for Arabic, it's mostly grammar, for German, it's both, and for other languages, it may be most if not all unrelated stuff. Of course, in no language all the letter combinations are words, and the chance to find a minimal pair (a pair of words that differs only in combining marks) is rather low, in particular if we limit ourselves to nouns, names, and other things that work in domain names. However, where there is such a pair, native readers will usually be well aware of it. Regards, Martin. From nobody Tue Apr 18 02:12:12 2017 Return-Path: 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 BB5DC1294C4 for ; Tue, 18 Apr 2017 02:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 pNw5RFXXaFX3 for ; Tue, 18 Apr 2017 02:12:09 -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 6AB4B131860 for ; Tue, 18 Apr 2017 02:12:05 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0PB2-000BDV-Ju; Tue, 18 Apr 2017 05:12:00 -0400 Date: Tue, 18 Apr 2017 05:11:54 -0400 From: John C Klensin To: Gervase Markham , Rodger Combs cc: idna-update@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:12:11 -0000 --On Tuesday, April 18, 2017 09:03 +0100 Gervase Markham wrote: > On 18/04/17 06:00, Rodger Combs wrote: >> * Make no change to names as used in DNS. >> * Instead, each registry maintains an internal database of >> "folded" variants of domains, and refuses new domains which >> "fold" to a value matching that of an existing one. >=20 > That is the correct solution, and is what Mozilla is arguing > for (with "fold" being defined by the Unicode confusables > list). Now your only problem is persuading registries to > implement it. Gerv, Good to know you are still watching this list. =20 I would have said "part of a correct solution", not a complete solution. It is fully consistent with something IDNA2008 calls for although it does not specif9ically require it in that form: That registries take final responsibility for understanding the characters they allow and, more generally, what they are doing (see draft-klensin-idna-rfc5891bis, which should probably be updated to explicitly call out not allow labels in the same zone that can be confused with each other. However, that gets tangled up with two other problems, one of which makes its applicability harder and that other of which has turned into a long-simmering dispute: (1) ICANN has been going in the direction of what they refer to as "variants" in which similar or confusable strings are identified. All but one can then be blocked (consistent with your proposal) or one or more can be delegated as long as they are delegated to the same party (see my previous note about one problem with that). The idea of delegating similar labels rather than blocking them seems to me to be in direct contradiction of your proposal. (2) Identifying strings as similar and then blocking all but one of them from registration can cause a lot of false negatives as people's guesses about how a particular string (e.g., one they see in printed form) is transposed into the DNS turn out to be inconsistent with the particular variation the registrant selected or the registry allowed. False negatives are, I trust obviously, much better than false positives, especially from a security standpoint, but users not being able to find the names they think they are looking for upsets both them and registrants. That issue is one of the things that has driven the desire for for widespread mapping of multiple characters onto a single one, even though that causes its own set of problems, as discussed in one of my earlier notes. There is another issue that, depending on one's point of view, either makes the above hard or brings us right back to where you (wisely, IMO) started in this area. We have some empirical evidence that there are registrars and registries out there that either don't care or even that have built their business models on selling confusion (e.g., "you need to buy this label because otherwise it might be confused with one you care about and then cause you harm"). There is even evidence that this is not "some" registrars but the majority of them and a lot of registries who either tolerate them or hide behind readings of ICANN guidelines and contracts that don't allow them to reject registrations. AFAICT, the only solutions available to a browser developer who considers that behavior dangerous are=20 (a) Keep a list of registries who behave in a careful and reasonable fashion and insist that registrars selling names in their domains do so too. Everyone else sees labels displayed in A-label form, threatening warning messages, strings that you simply refuse to look up, or a combination. That was, IIR, your idea and where the idea that browsers should take responsibility if ICANN and registries will not started. Note, however, that this approach may be of limited use if bad behavior occurs below the second level of the DNS tree. (b) Browser vendors, users, and those with security concerns increase the pressure on ICANN (and, for ccTLDs, relevant governments) to push back strongly on registries and registrars who won't take responsibility or who otherwise encourage problematic collections of labels to be registered. To me, such a change in policy is the single most important step that could be taken at this stage and it has the advantage of not requiring changing code (even if it were to require phasing out some existing labels that now exist only for confusion-causing or confusion risk minimization purposes. However, unless and until there is a major outcry, it seems obvious that this idea will go nowhere -- there is no profit in blocking a label, at least unless one can charge a fee for doing so. Some recent episodes on the ICANN side in which registries have taken the position that they can and will go ahead and register labels that clearly violate IDNA2008 (and, in important cases, even IDNA2008) registration rules because they think they can make money (often expressed as "uses want these" and ICANN can't or won't stop them reinforce that cynical view. (c) Either the same parties in (b) or others start resorting to litigation or criminal charges against registries that allow registrations that actually cause harm. There may be countries in which deliberately misleading users is allowed and encouraged by law and normal commercial practices, but, if there is, I don't know where it is. Turning confusing registrations from a positive-sum game from registries and registrars into a highly risky one would change the discussion in very significant, and IMO useful, ways. Whether efforts should be made to involve ICANN as a party to those actions -- especially now that it doesn't have whatever protection the US Government relationship brought-- is an interesting, but separate question. Three more observations for Rodger: (i) As you sort of point out now, UTS#39 does not cover all of the cases that might reasonably be considered relevant. Whether that is a serious defect, opening up systems to attacks it does not catch, or a collection of edge cases that fall under the "can't find a perfect solution to all of this but it is best to do what one can" is a matter of perspective and opinion. Similarly, focusing on "combining marks" creates some dependency on seemingly-arbitrary (and/or language-dependent within the same script) decisions by Unicode about what single-code-point representations for characters do and do not decompose. That is the reason why the U+00F8 case is important: in that character, the slash is not a diacritical mark so there is a presumption that registration of a string with "o" does not block one with "=C3=B8" from being registered. However, because "=C3=B6" does decompose, it would be blocked. Whether we like it or find it appropriate for IDNs or not, there are sound Unicode coding reasons for that distinction, but explaining them to users is a real issue (see draft-klensin-idna-5892upd-unicode70 for a more general exploration of the problem, but note that it is officially expired and that there is an updated replacement that has not been posted). (ii) It seems that your latest approach bypasses the problem that got you (and others) started, which is the ability to construct entire labels on one script that look a lot like labels constructed entirely in a different one. That is still covered by the principle that registries need to be careful and take responsibility for not allowing two labels in the same zone that could pose difficulties of confusion. (iii) You should be careful about NFKD (or NFKC), since some of the so-called compatibility equivalents may not be appropriate substitutions in all cases. Again, as a way of figuring out that there are a pair (or more) of labels only one of which should be allowed to be registered in a given zone, it may be fine. As a way to determine which one should be chosen, there are several subcategories of compatibility equivalents, some of which seem globally reasonable and others of which include problematic and usage-specific cases. IIR, we discussed that issue in RFC 4690 as well. best, john From nobody Tue Apr 18 02:19:24 2017 Return-Path: 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 131DC1294E0 for ; Tue, 18 Apr 2017 02:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-org.20150623.gappssmtp.com 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 sfIU3wviD2VP for ; Tue, 18 Apr 2017 02:19:20 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41779131895 for ; Tue, 18 Apr 2017 02:19:11 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id o21so98042782wrb.2 for ; Tue, 18 Apr 2017 02:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QS86FW/x5nPzBoEHwM8T06jGHwfKsS08AU6yypgB8aA=; b=zDz/ZP3GT5l++rc1njqDoj4s4zEyPPuHmGCKNDhKxnOtBCg/Wfp/1Yzm22+6yBAxmF xMrr0j3ainfYyZu7qMKoMzm0IWCi0KVm9wo1QZQvYp2KHb1tpJO3SOYYJ9vSTFbpfMQ8 VMUZVIkCwgDJwoA3VHEL+3BzivhHKSv8V7lqeei8kb4NBhKQ2F7jN4MpzVYJf6PeRYt8 x/z1NEAWeu3VO8kV9RojDM6vXSZrYH36IwIeoSjmS2u9AqcCrjUV0YFj7NNtcZqXJI4e Du0XnUPSekNFz4fkSg8t+MCtFRiDrhYuPnqvS2VkJuZ2z6/bfv8MvWM/qqu9ofa10alt X63A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QS86FW/x5nPzBoEHwM8T06jGHwfKsS08AU6yypgB8aA=; b=UO/VqneJyR3VdbO2UQrfF64gYR0LhJOl4dPQL1GBliIyhFbEGlJljivT8qNpZeH9EC rDGg/xMbp6gCvFY6Cu5zdKqxJPWfUpwQk4mhLflv6A2gp3qBwIHKZvdluu0FiUGm2m7W OUfRVA5U3dEb/1K2mjBWanaV4cNKi3pG/ZTSU6oCaDH2cr0MfKM4bcF+bgUjltEzHdAZ 8+DebQ+MJ2fP9c9Fs8kqpSRO/jiqcMDdUV6W3LhcA9TIZ/niEjjAdAdYUsZh+Z9uNQ85 iF9YnrL6NdzMB8QaUBZWFY2B3bLaee2jDCegaVRD4zLKOIZoXXIBkszx2zUST4LABbjb mg1Q== X-Gm-Message-State: AN3rC/7WQDsmx4z1ylyXNOm7siyWpRdBzIYbNFPIZndll2Ud2opjdakB 8kt5pb15CvLDdTFG X-Received: by 10.223.171.6 with SMTP id q6mr22062887wrc.147.1492507149638; Tue, 18 Apr 2017 02:19:09 -0700 (PDT) Received: from [192.168.0.105] (cpc116904-shep14-2-0-cust913.8-3.cable.virginm.net. [80.192.227.146]) by smtp.gmail.com with ESMTPSA id h20sm14066838wmd.29.2017.04.18.02.19.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 02:19:09 -0700 (PDT) To: John C Klensin , Rodger Combs References: Cc: idna-update@ietf.org From: Gervase Markham Message-ID: Date: Tue, 18 Apr 2017 10:19:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:19:23 -0000 On 18/04/17 10:11, John C Klensin wrote: > (1) ICANN has been going in the direction of what they refer to > as "variants" in which similar or confusable strings are > identified. All but one can then be blocked (consistent with > your proposal) or one or more can be delegated as long as they > are delegated to the same party (see my previous note about one > problem with that). The idea of delegating similar labels > rather than blocking them seems to me to be in direct > contradiction of your proposal. I don't think so. I think either bundling or blocking solves the problem, and am happy with either or both, at the registry's choice. The key thing is that two visually-identical domains should not be owned by two different parties. > (2) Identifying strings as similar and then blocking all but one > of them from registration can cause a lot of false negatives as > people's guesses about how a particular string (e.g., one they > see in printed form) is transposed into the DNS turn out to be > inconsistent with the particular variation the registrant > selected or the registry allowed. False negatives are, I trust > obviously, much better than false positives, especially from a > security standpoint, but users not being able to find the names > they think they are looking for upsets both them and > registrants. That issue is one of the things that has driven > the desire for for widespread mapping of multiple characters > onto a single one, even though that causes its own set of > problems, as discussed in one of my earlier notes. Sure. But this is a registry UX problem. Probably the best method and the most user-friendly one would be bundling of all variants, and if you type any one of them in, you get the opportunity to register the entire bundle, ideally at the same price as a single name. Or, if they charge per-name, you can pick some, and the others will be blocked. That's what a responsible registry would do, I feel. > (wisely, IMO) started in this area. We have some empirical > evidence that there are registrars and registries out there that > either don't care or even that have built their business models > on selling confusion (e.g., "you need to buy this label because > otherwise it might be confused with one you care about and then > cause you harm"). There is even evidence that this is not > "some" registrars but the majority of them and a lot of > registries who either tolerate them or hide behind readings of > ICANN guidelines and contracts that don't allow them to reject > registrations. I can imagine this is true. I suspect that only public pressure, and pressure from their customers (domain owners who don't want to be attacked) will change this. And the first step in that is putting responsibility where it belongs. > (a) Keep a list of registries who behave in a careful and > reasonable fashion and insist that registrars selling names in > their domains do so too. As you may know, Firefox used to adopt that policy. However, the gTLD explosion made us abandon it as non-scalable. See: https://wiki.mozilla.org/IDN_Display_Algorithm > (b) Browser vendors, users, and those with security concerns > increase the pressure on ICANN (and, for ccTLDs, relevant > governments) to push back strongly on registries and registrars > who won't take responsibility or who otherwise encourage > problematic collections of labels to be registered. To me, such > a change in policy is the single most important step that could > be taken at this stage and it has the advantage of not requiring > changing code (even if it were to require phasing out some > existing labels that now exist only for confusion-causing or > confusion risk minimization purposes. However, unless and > until there is a major outcry, it seems obvious that this idea > will go nowhere -- there is no profit in blocking a label, at > least unless one can charge a fee for doing so. Some recent > episodes on the ICANN side in which registries have taken the > position that they can and will go ahead and register labels > that clearly violate IDNA2008 (and, in important cases, even > IDNA2008) Typo here? Gerv From nobody Tue Apr 18 02:27:01 2017 Return-Path: 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 E973F12955A for ; Tue, 18 Apr 2017 02:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 m7XExiuNKAwC for ; Tue, 18 Apr 2017 02:26:59 -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 2DBAB129559 for ; Tue, 18 Apr 2017 02:26:56 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0PPM-000BEz-1I; Tue, 18 Apr 2017 05:26:48 -0400 Date: Tue, 18 Apr 2017 05:26:41 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Rodger Combs , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: idna-update@ietf.org, Asmus Freytag Message-ID: <726E1120F4ADDB165E600159@PSB> In-Reply-To: <4f041d48-b99f-2cc9-f1a2-c93781663743@it.aoyama.ac.jp> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> <4f041d48-b99f-2cc9-f1a2-c93781663743@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:27:00 -0000 --On Tuesday, April 18, 2017 17:50 +0900 "Martin J. D=C3=BCrst" wrote: >... > Of course, in no language all the letter combinations are > words, and the chance to find a minimal pair (a pair of words > that differs only in combining marks) is rather low, in > particular if we limit ourselves to nouns, names, and other > things that work in domain names. However, where there is such > a pair, native readers will usually be well aware of it. And, of course, there are lots of domain names that are not words but that are, instead, abbreviations, acronyms, codes, or assorted constructions that might be words but aren't. Consider both constructions like "MyBigCompany.example" and even popular TLDs like "com", "biz", "int", and even "arpa" and almost all ccTLDs. Even "no mixed script" rules and strings that are not visually confusable run afoul of other principles. For example, there is a large toy store operation, with many stores in the US and some on other places, that has a trademark on = "toys-=D1=8F-us". I'm confident that they believe they have a right to register that string, and its non-hyphenated variation, in the DNS regardless of whether they have done so or not and that they have the right (and perhaps obligation) to block registration of any of those strings and "toys-r-us" etc. from being registered and used by anyone else. "toys-=D1=8F-us" would be blocked by a = "no mixed script labels" rule, but I'm also fairly confident that they wouldn't have to look very long to find a judge who would agree with them that any registry rules that prevented them from using their trademark in an obviously important context was invalid and could not be enforced. Again, no perfect solutions here and relying on "words" isn't even close. best, john From nobody Tue Apr 18 02:29:38 2017 Return-Path: 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 E2C8312957A for ; Tue, 18 Apr 2017 02:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 J5ktfUsTuQVf for ; Tue, 18 Apr 2017 02:29:37 -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 05804129573 for ; Tue, 18 Apr 2017 02:29:37 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0PS2-000BFH-EL; Tue, 18 Apr 2017 05:29:34 -0400 Date: Tue, 18 Apr 2017 05:29:27 -0400 From: John C Klensin To: Gervase Markham , Rodger Combs cc: idna-update@ietf.org Message-ID: In-Reply-To: References: 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.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:29:38 -0000 --On Tuesday, April 18, 2017 10:19 +0100 Gervase Markham wrote: > clearly violate IDNA2008 (and, in important cases, even >> IDNA2008) > > Typo here? Tep. Second one should have been "IDNA2003". Clear evidence that I need a nap. Sorry. john From nobody Tue Apr 18 03:10:53 2017 Return-Path: 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 0D412129B88 for ; Tue, 18 Apr 2017 03:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 T8_ek-Rw6PPH for ; Tue, 18 Apr 2017 03:10:50 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E87D129B82 for ; Tue, 18 Apr 2017 03:10:50 -0700 (PDT) Received: from [77.72.226.191] (unknown [IPv6:2a01:3f0:1:0:973:e941:a576:214e]) by mail.frobbit.se (Postfix) with ESMTPSA id 800C920201; Tue, 18 Apr 2017 12:10:44 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Rodger Combs" Cc: "Asmus Freytag" , idna-update@ietf.org Date: Tue, 18 Apr 2017 12:10:44 +0200 Message-ID: <4C123C0A-66BF-44E6-941A-3747F03E9D8E@frobbit.se> In-Reply-To: References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_ACFDFCB4-60CF-4D64-9C10-69956AD62291_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6082) Archived-At: Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 10:10:52 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_ACFDFCB4-60CF-4D64-9C10-69956AD62291_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 18 Apr 2017, at 10:17, Rodger Combs wrote: > I completely understand this, but it's besides the point. What I'm sugg= esting at this point is that registries effectively ban new registrations= that differ from existing registrations only in combining marks, _not_ t= hat combining marks themselves not be allowed in actual domains, and I ne= ver suggested that they not be _displayed_. This sentence above does not make any sense to me, and/or is very latin/g= reek/cyrillic centric view on what "combing mark" is (which is though not= true for all code points in latin/greek/cyrillic, see for example use of= Latin Script in Catalan Language or Turkish). What I think you are talking about is confusability, and lately we have s= een cross script confusability. Which is a completely different issue tha= n combining characters, and more related to what the LGR panels have been= working with. paf --=_MailMate_ACFDFCB4-60CF-4D64-9C10-69956AD62291_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlj15iQACgkQrMabGguI182rHQCfQBPbWKPOUtD1dXPv69jbJUFU IzAAn3mLvjUeM5h47CqmTgF7sqlQotzQ =ly05 -----END PGP SIGNATURE----- --=_MailMate_ACFDFCB4-60CF-4D64-9C10-69956AD62291_=-- From nobody Tue Apr 18 06:52:26 2017 Return-Path: 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 BF2D01316D0 for ; Mon, 17 Apr 2017 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 fOcEaaZlZFSI for ; Mon, 17 Apr 2017 10:23:29 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D431313167A for ; Mon, 17 Apr 2017 10:23:26 -0700 (PDT) Received: from [169.254.101.221] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3HHN85j057135 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Apr 2017 10:23:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.101.221] From: "Paul Hoffman" To: idna-update@ietf.org Date: Mon, 17 Apr 2017 10:23:25 -0700 Message-ID: References: <149244587825.17738.2510740345439278713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 06:52:25 -0700 Subject: [Idna-update] Fwd: Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:23:31 -0000 Forwarded message: > From: The IESG > To: IETF-Announce > Cc: alexey.melnikov@isode.com, > draft-freytag-lager-variant-rules@ietf.org, shollenbeck@verisign.com > Subject: Last Call: > (Variant Rules) to Informational RFC > Date: Mon, 17 Apr 2017 09:17:58 -0700 > > The IESG has received a request from an individual submitter to > consider > the following document: > - 'Variant Rules' > as Informational RFC > > Some comments were raised in IETF LC about how this document relates > to RFC 7940. The document was updated to clarify that. > This is a Second IETF LC to make IETF community aware of changes > to this draft. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-05-15. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > Rules for validating identifier labels and alternate > representations > of those labels (variants) are known as "Label Generation Rulesets" > (LGRs); they are used for the implementation of identifier systems > such as Internationalized Domain Names (IDNs). This document > describes ways of designing Label Generation Rulesets (LGRs) that > support variant labels. In designing LGRs, it is important to > ensure > that the label generation rules are consistent and well-behaved in > the presence of variants. The design decisions can then be > expressed > using the XML representation of LGRs that is defined in RFC7940. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 18 07:04:20 2017 Return-Path: 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 31EDA1316CD for ; Tue, 18 Apr 2017 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ClracT9ZWsl1 for ; Tue, 18 Apr 2017 07:04:17 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8179E12EC29 for ; Tue, 18 Apr 2017 07:04:11 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l189so69816591ywb.0 for ; Tue, 18 Apr 2017 07:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DPSx5bnUHnaJFUWTdR+15YbsLJAOyinaMHbPFqHKsbE=; b=ZqDxx+q5Cn1o/kNNkVOv9Po9QcPET36kHSoNHTSckD6+A89RnZgIOijeOR3bMu9pNe YITjhIf2mXaLiEMOqfXlD+ChJVoSm24s/Jo0IB8QQACYVpfe60T0c2QHagwZkv70k+8D QtRTrvm5CT2tg4IExnpqT9B/3PISfFE5EGqcGvIJ7BhkbzpxUzjDFdew8JsJzVcmQeBC hIN29FIgNI3Z6vFcD4O97WzA4jpmCmtfv7okwbFJYsyl9GXI3ai8exPXNnMGt8G2HxYM 4Z15z2/Erl7qI6rrCwwDX/i0F7xwHxq0mzNj+acWNgP/orTwdvmE1Z2Q9n/HrUEiWkve 4sXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DPSx5bnUHnaJFUWTdR+15YbsLJAOyinaMHbPFqHKsbE=; b=Zvf03PHxpycg0cQlaeX1XgVVGDGcLlCXt5zx/VOpd3lxQ6DRW6UTtRkkakD6ADWWEa xwiQuaSkNmLtpGF2NLmEWIAhL44HMgRfHGtnSCgNC0m9ftDitd1Z70N/d2EgbvoZUgUW eITUm4wBQwDMoFq5SOhxMvYoviW92rKzFuDhrZR9MgoKIUX2uxsXkp55xyZgxkPIJPGB El7EyTlc6VN6kX4VB2qbGd+nVj3siQAXSlShR+ugUZn5OlWtr9suM+ELQk3HZy9cg5QS lLqfPgEiJYWqJA11rIEqliURL9JWUfzTNwlDmn6pS+Qx5MMQieUPXzbJj7Bh2wS6BFC/ jxbQ== X-Gm-Message-State: AN3rC/4c8Eqbp5iFlSBKWUruAqyGZhHZC8VZFL1/8YTtNGcKeZ6DphbJ ZZUHJbTKnRvq0hZVblNJz4KwH1wMWJaDCi0= X-Received: by 10.157.27.164 with SMTP id z33mr7393210otd.122.1492524250586; Tue, 18 Apr 2017 07:04:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.18.208 with HTTP; Tue, 18 Apr 2017 07:04:09 -0700 (PDT) In-Reply-To: References: <149244587825.17738.2510740345439278713.idtracker@ietfa.amsl.com> From: Vint Cerf Date: Tue, 18 Apr 2017 10:04:09 -0400 Message-ID: To: Paul Hoffman Cc: idna-update@ietf.org Content-Type: multipart/alternative; boundary=001a1141a834c6b4d3054d7161e3 Archived-At: Subject: Re: [Idna-update] Fwd: Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:04:19 -0000 --001a1141a834c6b4d3054d7161e3 Content-Type: text/plain; charset=UTF-8 if this is published, I hope it is made clear that this is not a standards recommendation endorsed by the IDNA working group. v On Mon, Apr 17, 2017 at 1:23 PM, Paul Hoffman wrote: > Forwarded message: > > From: The IESG >> To: IETF-Announce >> Cc: alexey.melnikov@isode.com, draft-freytag-lager-variant-rules@ietf.org, >> shollenbeck@verisign.com >> Subject: Last Call: (Variant >> Rules) to Informational RFC >> Date: Mon, 17 Apr 2017 09:17:58 -0700 >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Variant Rules' >> as Informational RFC >> >> Some comments were raised in IETF LC about how this document relates >> to RFC 7940. The document was updated to clarify that. >> This is a Second IETF LC to make IETF community aware of changes >> to this draft. >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2017-05-15. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> Rules for validating identifier labels and alternate representations >> of those labels (variants) are known as "Label Generation Rulesets" >> (LGRs); they are used for the implementation of identifier systems >> such as Internationalized Domain Names (IDNs). This document >> describes ways of designing Label Generation Rulesets (LGRs) that >> support variant labels. In designing LGRs, it is important to ensure >> that the label generation rules are consistent and well-behaved in >> the presence of variants. The design decisions can then be expressed >> using the XML representation of LGRs that is defined in RFC7940. >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-freytag-lager-variant >> -rules/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 --001a1141a834c6b4d3054d7161e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
if this is published, I hope it is made clear that this is= not a standards recommendation endorsed by the IDNA working group.
v


On Mon, Apr 17, 2017 at 1:23 PM, Paul Hoffman <= paul.hoffman@vpnc.org> wrote:
Forwarded message:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: alexey.m= elnikov@isode.com, draft-freytag-lager-variant-rules@ietf.org= , shollen= beck@verisign.com
Subject: Last Call: <draft-freytag-lager-variant-rules-05.txt> (= Variant Rules) to Informational RFC
Date: Mon, 17 Apr 2017 09:17:58 -0700

The IESG has received a request from an individual submitter to consider the following document:
- 'Variant Rules'
=C2=A0 <draft-freytag-lager-variant-rules-05.txt> as Information= al RFC

Some comments were raised in IETF LC about how this document relates
to RFC 7940. The document was updated to clarify that.
This is a Second IETF LC to make IETF community aware of changes
to this draft.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2017-05-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

=C2=A0 =C2=A0Rules for validating identifier labels and alternate represent= ations
=C2=A0 =C2=A0of those labels (variants) are known as "Label Generation= Rulesets"
=C2=A0 =C2=A0(LGRs); they are used for the implementation of identifier sys= tems
=C2=A0 =C2=A0such as Internationalized Domain Names (IDNs).=C2=A0 This docu= ment
=C2=A0 =C2=A0describes ways of designing Label Generation Rulesets (LGRs) t= hat
=C2=A0 =C2=A0support variant labels.=C2=A0 In designing LGRs, it is importa= nt to ensure
=C2=A0 =C2=A0that the label generation rules are consistent and well-behave= d in
=C2=A0 =C2=A0the presence of variants.=C2=A0 The design decisions can then = be expressed
=C2=A0 =C2=A0using the XML representation of LGRs that is defined in RFC794= 0.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-freytag-lager-variant-rules/

IESG discussion can be tracked via
https://datatracker.ietf.o= rg/doc/draft-freytag-lager-variant-rules/ballot/


No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.= org
https://www.ietf.org/mailman/listinfo/idna-upd= ate



--
Ne= w postal address:
Google
1875 Explorer Street, 10th Floor
=
Reston, VA 20190
--001a1141a834c6b4d3054d7161e3-- From nobody Tue Apr 18 09:38:35 2017 Return-Path: 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 DE3AA12EE46 for ; Tue, 18 Apr 2017 09:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CUiv_nx1exVL for ; Tue, 18 Apr 2017 09:38:33 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AB012EC9E for ; Tue, 18 Apr 2017 09:38:32 -0700 (PDT) Received: from [169.254.41.181] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v3IGcCik001293 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 09:38:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.41.181] From: "Paul Hoffman" To: "Vint Cerf" Cc: idna-update@ietf.org Date: Tue, 18 Apr 2017 09:38:29 -0700 Message-ID: <9249DBEB-E1D8-45B9-85FB-056AC4C4080F@vpnc.org> In-Reply-To: References: <149244587825.17738.2510740345439278713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Idna-update] Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:38:34 -0000 On 18 Apr 2017, at 7:04, Vint Cerf wrote: > if this is published, I hope it is made clear that this is not a > standards > recommendation endorsed by the IDNA working group. It says "Informational" right at the top of the document, and that's the best we can do for the RFC Series. There is no IDNA Working Group any more, so there is no way to say that it was not endorsed by this WG. The document is, however, intending to be an IETF consensus document. --Paul Hoffman From nobody Wed Apr 19 00:21:07 2017 Return-Path: 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 36A1E12EC57 for ; Wed, 19 Apr 2017 00:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 GkMJpJWYRwWl for ; Wed, 19 Apr 2017 00:21:05 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0136.outbound.protection.outlook.com [104.47.92.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94118126CD8 for ; Wed, 19 Apr 2017 00:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0xCZo881zhqFEBWRQkL3XTrsBMwDCXHUWpTXojGrq+M=; b=YH0zVWzozkfv15xaTvi1R9gfj/b2UHt/WeZYe8yfvk9gq4PD3YTmX27ezf6pSMaewrfk0ckSduEEwTmu6BClmhV41NBV6W6tFfWYVKrlllShVvrrpwWLkb2aZ7E27VJWHokQ/7eswktXaNebnq2k9UMAAXxkSKToOJuueqt8fYw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [100.70.12.254] (133.2.59.38) by TYXPR01MB0654.jpnprd01.prod.outlook.com (10.168.43.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 07:21:02 +0000 To: Paul Hoffman , Vint Cerf References: <149244587825.17738.2510740345439278713.idtracker@ietfa.amsl.com> <9249DBEB-E1D8-45B9-85FB-056AC4C4080F@vpnc.org> CC: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 19 Apr 2017 16:20:57 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9249DBEB-E1D8-45B9-85FB-056AC4C4080F@vpnc.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.59.38] X-ClientProxiedBy: OSXPR01CA0054.jpnprd01.prod.outlook.com (10.167.144.40) To TYXPR01MB0654.jpnprd01.prod.outlook.com (10.168.43.141) X-MS-Office365-Filtering-Correlation-Id: 5f2db5f1-8054-4b24-1d31-08d486f4a2a8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:TYXPR01MB0654; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0654; 3:dbE79QiU5zWcofVP1admsjGm9nLgy2qsvPH8kreRtPmBfDkHBlbzU1HZlcmnrnhJ3sZ60OzxXPqaTf34vnrKbNAXz2Gf42X2XODQVyKNww+fWRczYLQnh8rsoZyT1JJ31NE3hdvB5CzMDEOnMK7eqPWES5u83qZ36lZHjjDSZ7vds21XeIiyjsDPNtuAGLAxyENPouXbRUTdt/eBln8G8NNkz2l8Mf/6WePemo6+9eaqNM2VWtNKoIZCY/1XFCU8YoJymu+IQhGQeKnbfqMfeOHGecIgCIpFcvL4Ku0WO6IXUhiPV8chC7VkET+EJeimoYoWDXErWl0Zn8UJD1W3ZA==; 25:2G0K0olszEEXiQ+iewg7xZaQItQriERuaEu2eLggzRBInIo+L94QF5p8y999WXfSGyjFGo2BiLQUvp6zPHzfoiqWagYvz+DbYnKrTJuYjEKFpcuRVuo6C0Jxu+p43ai3Q6Cc0KvyMBsvbPuAF9DJKsO337Ye04tsCBBdHe+lhBdCcg5QJ8ugGQfTn3GMzHZVwhfyt8uNL4mD/MmgdpA+XSXRoxUOHVP4wMM1MlxRmEvpxEbTmVC1MF0BR7oTQUNXm5xqmOQs3L1/fiy2i1yXCYFuIeeo3xzvDSuMGpJ5wzgr4GxGAe0m3BrXQkVk5myxZ1rpU/UQSp7ky9NwXR6O8pXnr3i4cFPBj33vAD5k7n2UD9pz1xMwOPPyri+hIdmOnf3jYZJzLZBLgTiSPSGSlBao6xLDJryavdMhNqpha0j7E/6e9bQosGXeQDyi3o2jCmIBZGQfJqfgvykXlVtkvQ== X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0654; 31:mRcAl1QdtVDoUOtnS+2Afofl2Gi0a2NRHQgAIA6eLHMQDif9q7nhLpVgrlWApdhC/WapafVNxsSzoEsSoisP0iVp0q5eiKa6nwsl2M+nxnFaUnrc2AyFXpBbhz85cIXhBqq1md8MSGGx+vvFBKYi4/fVznhcbZXbDbnTqjnT9Xpty3Cv8CsJsb3GMAKMaAmGV8csrRcEqEgMpq5Dh+MUY1gbpaFL0/a2r66In9ZCBgVWrX/W82tn7Whhxdsd1b7xUG74/nbrpOfZBgMr2xr1niNFTKAK5nUDWLTijR35uRQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201703061421075)(20161123555025)(6072148); SRVR:TYXPR01MB0654; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0654; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0654; 4:bBWI1RKKWZGpdua/+BAQvl3OZLtQSprxt6WvqjxiG0FpnwGVdMc6Z8NNKNEsIH9LHnwfO92Kjyb6M8DSqqMchCOiUdrnj02LXIYyVt46dYSa055kdmOoidfhC+CfEp03VXqZo4PeKR7Y7MfXzKLALUq2qGzQOXiXcoQECbh/aLpIzSxecypSjxQnXz+bvvaVuYe/yB31lZcmHxsVNE8tLnOKHWVlSmVw6/GAiZv5mOiu0VgpLhKIw2f8tJlLbhBW2YlRR88y2a2tR5ckrZ1mmu8cXT38ac5bcjJMM9h7Oibicd7CA4ORj1PdTxUVTcQiQ0XWSOIE1cemBC3BdDLdYwShooovHdidtmzH38jILnEVeTsDgbT6trZLCeimULBRKrM26Ni6V+PvSSFtL7xXaZrNrhc48tbM3EzAuYSVx8ROPP77ncLMg2Bkze6i33Giw4UxskMVdp/yapA45u/cHCnieuZ+8o1kZz2Nyy479WzDymI25xrsw5ACUr4+RI0vF6r7mecH7vdYjI3f9NTN7Phk9ChMEuRiLqUL07OIF5GtIhUr3WZek+wO/6QVy9CNVfnJGXauH+XyNoehyDLCElkukRumB2k8xia8tLm0HNTlxysNOXoNBz6a4GJgO9SSKZfPRlaeEhDok+2mw6pr3g9bC5oUwG6cTLJn6DJNd7LXfkszh4Q46k5h6S5UjZCz3tWx+br2Ha+10xG74YSf0TsLBSa5ggvI7F3xznaXuln7dsCYgZCR+yLXvF5XmlpO X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(39400400002)(24454002)(25786009)(3846002)(2906002)(305945005)(53546009)(6116002)(38730400002)(23676002)(230783001)(53936002)(7736002)(76176999)(65956001)(54356999)(74482002)(50986999)(65806001)(230700001)(31686004)(4326008)(33646002)(31696002)(47776003)(93886004)(42186005)(66066001)(86362001)(189998001)(83506001)(2950100002)(64126003)(229853002)(42882006)(6666003)(4001350100001)(65826007)(8676002)(5660300001)(6486002)(50466002)(81166006)(90366009)(78286005); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0654; H:[100.70.12.254]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwNjU0OzIzOnJFYmZzK3VaSmgvK2h2RFZmMVZzWFRQM0Vw?= =?utf-8?B?elcrb2cvaVh1WU1wMFI3Y04wdmJmT3hPTzgrNlpwYzh4SE9aZWVubEl1bW0z?= =?utf-8?B?NG9ERU43MnlndWxCalEvZ1BNTnBSaUh3RUUwc3plSG1WWHlXaDZWQXVUZEM1?= =?utf-8?B?L1ZpaTQrNWRJZVlVd2FSVXNCRExpNGFSbDZIVlo5QWxHUlVraUtwWE91WXZv?= =?utf-8?B?Nm05QWt0V2padUhJZUVMNmZXbExmdDJjeTBFdHowanJkcGYxdzZDTlo0QnBi?= =?utf-8?B?aHMzRmxaUzN6KzNTUE1JUlFsYXA5K3VsSTRDc1hqZzBwcDBGRUQ2TE9CaCs1?= =?utf-8?B?eEttZWY2UTN2RVBibG1rZTEzMVhudGNodXdJVWFxQ3Nib21ETFNyTHhTQXZh?= =?utf-8?B?N3pWeHdPNmNVdUdPWDJNbytCSks4NkdQQUt2SDZUMndDZXR3N2doUDlSTFlL?= =?utf-8?B?ZUhwWGpJSmEyYk5qNFk3bUJMSnErNEpQTnc3VVdHRnBHdjhlYnA3VUpqSDBy?= =?utf-8?B?NTY2QWswR3ZJcEZqOHRhREVzOWlOWm9oNlZuMVBaT1AyR2dQaEVhNDlBbUJC?= =?utf-8?B?TzR3Tmlua2d3QVFDNlFmbmMvNFZJa2xiQm01Q2cwVWJGM3l4ckJKcE5RYTYz?= =?utf-8?B?SXJid1dtdUJYWXRKanIvYzQ4VFJ1V1VqS0hrNU1rVGFtSjRJZENadVFpY2dL?= =?utf-8?B?eGZNT09nOVlRa1UyZWlTZlU0eG54MHdHTXFFK21aM1pCaGZCMlVsN0ZCSWdq?= =?utf-8?B?ZlhIdTlIZmVJTzhHNTFxcUtrR1R1Vnc1UHlCWWpJZWcxMXhZQVJLQVhZS1hP?= =?utf-8?B?d3VkUFFZKzlWQmVidHZSaHZ6ZzF1WjR0UGkwWEw3akJ2VzA4UnNoNktPTXNu?= =?utf-8?B?aTVzWmx3UnFxV3ZWYndpSmx0YTM0Z1IyalM2aVYrYUJLYjZ6eW1VVUw0bEJs?= =?utf-8?B?ZDFOVTlDbE04ZG1hV2dpUE5YK0NpMmllM2h4Wm1QKzZNUnVLeU52eXE3anNj?= =?utf-8?B?NVdkeEpQbWYxd0hXTW9WME5UMGltZ0RHaEFVdjVWS0k2V09adHBFVFZteVdW?= =?utf-8?B?c3dWNHYzM2FoUGp3TEE5ZThuU1hWSHRsVUVtYi9Xa1RxTUsxakV5UXpBRXZE?= =?utf-8?B?eGE0bndKdUNWZENZSThxT3E3bDR1ZUM5RGgyNGtOajhtR0xQSkh0YTEwUTRO?= =?utf-8?B?TmVTcU15NFp3T1Nsc2hzdEE0MUJiUVY5NDlIZlJjcWhMN2VhNWhTZVV2QkZW?= =?utf-8?B?bVZ1Z0tFWWwyQ01jVU1iMlMraFJOZEU0WWdvMFhWUCtrdmx5Q2dZR05pMzBR?= =?utf-8?B?Ri9QQy9xUDV0RkppWU5aK21wNFZJU2lFWklpTzBMOHBJRzZ2MUxFZHlVSU1l?= =?utf-8?B?bVFLWVpsM09zbHVKZ01Bb1M5b0NIdERXd3FUdHBNQkVJdFNxWnlaV3BQV0x5?= =?utf-8?B?UGJHR2Q1VFNJd1EwR3lQdGxDNkJEUit1U1ZYazQzN2RHVkxUcG14MEhRUEZM?= =?utf-8?B?cGZmWXh4ak9ZWUx3UGRkNFZkVDl2S29za1pwWXQzeGh0YkpHQk1TeGVuMmJ6?= =?utf-8?B?UTE3T1E5ZlBQUW1pMjZMeEFnTElPektBamhVSFVnWG8zKzYyVDRKNm5QamVm?= =?utf-8?Q?xPXc6z0LmLJ80mckJRSB?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0654; 6:U94RyA5vpAZI1ryzsBO+WGxn6AnX08bqkcv169XZQsEqsqQvZ3yAmU3LaIFWTiB8CLiNrHx6Gqihb6gA7FTUckYdVRQ7+A4wvzhYbFef3G0f9KRYd/ugARNvWv9qILegeBPgzP65A6JJTazpBWy+LFh13D2Ue+mvQStpD7KMEpJ++eMLpM5FCPWh5Y99ujhUJLl3IgqHfWXUkccOqFFvKfRO8VaefMwgJSWeRPyb+xSLy99l+mhLDMQUms13GFE6dXrs8StvOELRjLrvmCfJ1KSD8mqgtH5cj3EcM48vgP5W65vWqyYVkv/6jAjpCXCvYcru0G3R+086AqDf0LSqFotPRWiF/50CNXr+XVJVd5KnaovGMQ4wqoUv5iWXKLEI1Jbqr5QYu6IGgWQQ+lDWsAezop2X6xyxMGhhL4EXD0wAR0TgTSDXgzYwY9rX1OK7MDgIPRSS4Z7i/FFyb+w4SA==; 5:EsN/J825JAgFQ+Gbk/ly76On1XHH9OGNK/aGkXi4/HRGaAoOLEbJBJ+Q13de6cn9i/38q+WFSMYW0wOcWBbFLodOt9F/B87eZ3wl7GrYHQJLS5hQ4vQ9ikjtTG2MqfbWlWnUAPhs041txUoHmKYxug==; 24:uepqRnQHGvY65Af2ZUtiTXPnubuDBn78SKd7Aqv/uHBuxIACXzBbAYivBAvcmbu0k9QW8YihSwi7szJmiHmFbOg/QvKN580bkHvjLFXKNes= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0654; 7:cUTHZYi9S655fXXm1npbOPa9UA2SObXIq4Pa+kIRiAASuhVsrj/CmRXqzHrtB1S4RjVu3ZHKkVX+MfubalZxU8UH64yKnbCWAaiaQWTJXac2CByXlvVj5ig4UfcgoDvxlOt1vGru8EwL/dSByKJb8kQji4wcgnFL4dHVt4IZT8HnPMQmukQUl1e6u2AnnIUj17RdrXdgv/fnBJr6z+f4U0yzB+h4ea3opClnrxRfOwjkUm6RkXhf4wbWk0i8yE+Q0uWqZblZNy6b+EXhzza2a6tTUeOdqm1/4is7V3aQPuQuFbulVRH30j5OW8ank5fsiw0COGJDJIYx1tdYt3UKcA== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 07:21:02.3359 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0654 Archived-At: Subject: Re: [Idna-update] Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:21:07 -0000 On 2017/04/19 01:38, Paul Hoffman wrote: > On 18 Apr 2017, at 7:04, Vint Cerf wrote: > >> if this is published, I hope it is made clear that this is not a >> standards >> recommendation endorsed by the IDNA working group. > > It says "Informational" right at the top of the document, and that's the > best we can do for the RFC Series. > > There is no IDNA Working Group any more, so there is no way to say that > it was not endorsed by this WG. The document is, however, intending to > be an IETF consensus document. Sorry to bring this up, but "there is no way to say that it was not endorsed by this WG" seems weird to me. Because the WG doesn't exist anymore, I think it's correct to say that "there is no way to say that it was endorsed by this WG" or "there is no need to say that it was not endorsed by this WG", or so. The result is the same, anyway: The document isn't endorsed by any WG. (and there's no need to say that explicitly) Regards, Martin. From nobody Wed Apr 19 06:20:14 2017 Return-Path: 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 B15DF129562; Wed, 19 Apr 2017 06:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 BMQcko1-gYsg; Wed, 19 Apr 2017 06:20:10 -0700 (PDT) Received: from bsa2.jck.com (ns.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 494E8129543; Wed, 19 Apr 2017 06:20:07 -0700 (PDT) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1d0pWa-000EiU-5F; Wed, 19 Apr 2017 09:20:00 -0400 Date: Wed, 19 Apr 2017 09:19:52 -0400 From: John C Klensin To: Paul Hoffman , Vint Cerf , alexey.melnikov@isode.com, draft-freytag-lager-variant-rules@ietf.org, shollenbeck@verisign.com, ietf@ietf.org cc: idna-update@ietf.org Message-ID: 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.70 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:20:13 -0000 Paul and IESG, While I think the clarifications in this draft are a considerable improvement, your response to Vint captures the concern about this document all along. To explain, I'm going to need to review some history, so apologies for probable length. The whole topic of DNS "variant rules" has been controversial among those who know about them and care from the beginning. They are much less so in the context of the root zone for which, the special names issues aside, ICANN has clear responsibility (and can make whatever rules they like, including the one to allow thousands of names, as long as IETF Standards are not violated -- and even the latter seems to be under threat), than for zones deeper in the tree and whether such rules are used there in a voluntary or involuntary. I note that, at the time ICANN first started allowing and encouraging IANA publication/ registrations of the characters that particular TLDs would allow in their zones, the ICANN Board (with support from me and the IAB), created that registry directly rather than requiring that the IETF establish the registry and rules for its maintenance. The idea was to try to help preserve and reinforce the separation implied by the above. We've also seen some history of documents being adopted (a deliberately vague term) in the IETF then being used to argue in ICANN processes that the IETF action means that ICANN has to implement then. That approach goes back to at least the CRISP effort (RFC 3707). That it has been unsuccessful in many cases is beside the point. That some of the efforts in the IETF have been strongly influenced by ICANN staff members who might (or might not) have planned to influence ICANN policy development processes in ways that they could not do directly may or may not also be an issue (and you, and other ICANN staff, may reasonably interpret all of those data differently than I do). So the IETF created a WG, LAGER, to do the core work on which this I-D was based, ultimately cumulating in RFC 7940. I note that, in recent years, we've had trouble getting enough traction to do meaningful work on any internationalization (i18n) issues -- IMO, EAI and PRECIS barely had enough active participation to justify a claim of meaningful WG consensus by the time their work wound down and other than a BOF (LUCID) that, IMO, never engaged with the key topics, the IETF has not been able to engage on the "non-decomposable character" issue despite a request from the IAB that it do so. I imagine that many people, even some of the i18n experts looked at the lAGER charter and said "if people want to get together and write some data representation rules around something that is basically an ICANN problem, I don't need to worry about it". I also imagine, reinforced by the few comments during IETF Last Call on what became 7940, that the Last Call reaction was similar. However, in that case, there _was_ a WG, the IESG reached the conclusion that the WG had sufficient membership and participation to be meaningful, and the community generally assumes that WG conclusions should stand as IETF ones if there is no meaningful and substantive dissent during Last Call. Then the IESG, in its wisdom and for reasons not announced to the IETF other than "concluded work" (such announcements are rarely made and I wouldn't propose to change it) closed down the WG. Then this document appears as an individual submission. There has been little evidence of wide review, especially by those with significant history of IDN involvement in the IETF. Perhaps that is in part because it shares the limited scope issues with LAGER and RFC 7940, requires a thorough understanding of that document and what it does and does not do, and, noting that the IAB just shut down its I19n Program after a long period of inactivity, there seems to be even less ability to get IETF traction on i18n issues than there was a few years ago. As I understand it, this document provides and explains a system to assist in developing and describing rules that might then be documented according to 7940. Even with the latest revision, it makes some assumptions that some of us (including, given his comment, I assume Vint) question in an IETF context (even if they represent ICANN consensus and are reasonable there because the scope, conditions, and support arrangements are different). At least in principle, the IESG could have reopened LAGER, gotten review there, and then pushed this through as a document from the same WG that was responsible for 7940. They didn't. But your conclusion was (out of context, but complete below) > There is no IDNA Working Group any more, so there is no way to > say that it was not endorsed by this WG. The document is, > however, intending to be an IETF consensus document. Right. There is no way to say that LAGER did not endorse it (or would not have endorsed it had it still existed). Likewise for IDNABIS. AFAIK, DNSOP and for that matter and, despite it (and 7940 (to pick a random example) LISP didn't consider it either. Since 7940 (last paragraph of introduction) and this document even more strongly claim that their data structures, mechanisms, and principles can be used for non-DNS identifier labels, perhaps the latter should have looked at it. But none of them did although, by your logic as I read it, there is no way to assume that they would not have endorsed it had they looked and therefore their assent must be assumed. For a claim of IETF consensus on an individual submission, especially one that is the slightest bit controversial (as this clearly is, even if one believes the controversy is about process, not substantive content), I think there has to be clear evidence of adequate and competent review of document content and relationship to other work to make that consensus claim meaningful. I don't think that has been demonstrated; YMMD. I also think that, if a document comes out of a WG and then one of its authors produces a individual document that suggests an extension, interpretation, or supplemental tools, we need to be extra-careful about that document and IETF consensus claims. YMMD about that too. Your response to Vint about what can be done about this was: > It says "Informational" right at the top of the document, and > that's the best we can do for the RFC Series. But that is not "the best we can do". The IESG can say "insufficient evidence of IETF consensus" and drop the document. I don't recommend that, but it is possible that others would disagree. The document can be handed off to the Independent Submission Editor with recommendation for publication with the usual clear statement from that Stream about there being no consensus assessment. Noting that all of the documents that started the "variant" epidemic (RFCs 3743, 4290, and, as a key example at least, 4713) were published in the Independent Stream and that didn't prevent them from getting community attention, there is probably little argument for the IETF Stream unless there is either clear evidence of consensus or if this document is really expected to be treated as a Standards Track supplement to 7940 independent of its official status. Or, in principle, the IESG could attach a note indicating that the document is published as a convenience and there is little or no evidence of informed IETF consensus about it. For me, it is precisely the claim that the document represents IETF consensus, or the now-demonstrated high likelihood that claim will be made, that is the problem here. That claim is, at best, not demonstrated to be true and, for a document that I believe lies very close to the boundaries of IETF scope and relationship to ICANN, I think we need to be extra careful about it when it is not demonstrably true (and not just because a series of current and closed WGs haven't commented on, much less endorsed, it). best, john --------------------------- For the information of the IESG and community, Paul forwarded the Last Call announcement to the idna-update mailing list. Vint responded there (but not to the IETF list or, AFAIK, to the IESG) and Paul responded to him (but, again, not to the IETF list or AFAIK, the IESG). Paul's response to Vint and, IIR, the substantive part of Vint's message appear below. --On Tuesday, April 18, 2017 09:38 -0700 Paul Hoffman wrote: > On 18 Apr 2017, at 7:04, Vint Cerf wrote: > >> if this is published, I hope it is made clear that this is >> not a standards >> recommendation endorsed by the IDNA working group. > > It says "Informational" right at the top of the document, and > that's the best we can do for the RFC Series. > > There is no IDNA Working Group any more, so there is no way to > say that it was not endorsed by this WG. The document is, > however, intending to be an IETF consensus document. > > --Paul Hoffman From nobody Wed Apr 19 07:52:41 2017 Return-Path: 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 98127129AC9 for ; Wed, 19 Apr 2017 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 kX_H8UF9Ywq1 for ; Wed, 19 Apr 2017 07:52:32 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C9E129AD1 for ; Wed, 19 Apr 2017 07:52:30 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id x184so30458798oia.1 for ; Wed, 19 Apr 2017 07:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F43vrZAi+b5LFudxLdsSJEDrhLxyoGOM5b7wNfJNfPE=; b=HPJ9KMvSvH02NgzNsbvbtMixjdqFe2synAF84vIhXN0ybg1OTooEbgNW7uwqFD22Ke nkUqkevP1PZHLOutTXeYEYLOSuTxqhPg+g4DOsp+QRLstXIQmLhD2W7mG8K+Vc9DURKT Z6qGLQxkHe+SRvd21QqJdNf6sErBc7TBMsLCrhdw/zrr0qmJBUr0EM3MKvCUmxYGMMfW 15Ml8OI3maMP1wU85QV3BOKfY23KsKL/TUCqHMPSpbN+seUGsnnY5t3VoGDUAXpdnW3V HHrFYHGmll1NvqrkxmAJyl87PBCNrHXvSSkJnfAl6jhsbQOm7Mp7cLNizx+Xj2MqvD2C I2fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F43vrZAi+b5LFudxLdsSJEDrhLxyoGOM5b7wNfJNfPE=; b=mTT5smPwebl0udZg6MmnN3a/T5i4YtYOnSCPt4o2HdvsidXZG2C2SgV4skV3Aj5iSk Emqep0eY0e86jebFggr0OXY/y/WeyX5NLE2slfBYpKZXbxaNqCzytwo8POJkkXtOfnG0 54w3e/b0IDYHraQFLOqkbD6WShAGOqLlbTxS3Zf5BynX2sG7ZgxSi/NFd5pwcgO/DTWv qOt3taVuSHPuAA6ypXUDV0tgac0Apu+CCMio+Me6l9XZDs0u1bSPASq7PJWA6MTwwpLI G+XbL/sw849/6v0veFkjyQdr+6fd/8Ys0VayaAnEcHGrPgIbRJTKogokxJhU1rMUBuWg GHsw== X-Gm-Message-State: AN3rC/7v8yQE+F2DsEKKJpnumggaF1dtplWC517B5vg3wKcbijPTy/N4 MH/dNuOiz6/AocpN0VhqjqSZFnTnnPWW X-Received: by 10.157.54.147 with SMTP id h19mr1540423otc.156.1492613549477; Wed, 19 Apr 2017 07:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.18.208 with HTTP; Wed, 19 Apr 2017 07:52:28 -0700 (PDT) In-Reply-To: References: From: Vint Cerf Date: Wed, 19 Apr 2017 10:52:28 -0400 Message-ID: To: John C Klensin Cc: Paul Hoffman , Alexey Melnikov , draft-freytag-lager-variant-rules@ietf.org, shollenbeck@verisign.com, IETF-Discussion list , idna-update@ietf.org Content-Type: multipart/alternative; boundary=001a11c16cc667b0c6054d862c57 Archived-At: Subject: Re: [Idna-update] Last Call: (Variant Rules) to Informational RFC 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:52:36 -0000 --001a11c16cc667b0c6054d862c57 Content-Type: text/plain; charset=UTF-8 +1 v On Wed, Apr 19, 2017 at 9:19 AM, John C Klensin wrote: > Paul and IESG, > > While I think the clarifications in this draft are a > considerable improvement, your response to Vint captures the > concern about this document all along. To explain, I'm going to > need to review some history, so apologies for probable length. > > The whole topic of DNS "variant rules" has been controversial > among those who know about them and care from the beginning. > They are much less so in the context of the root zone for which, > the special names issues aside, ICANN has clear responsibility > (and can make whatever rules they like, including the one to > allow thousands of names, as long as IETF Standards are not > violated -- and even the latter seems to be under threat), than > for zones deeper in the tree and whether such rules are used > there in a voluntary or involuntary. > > I note that, at the time ICANN first started allowing and > encouraging IANA publication/ registrations of the characters > that particular TLDs would allow in their zones, the ICANN Board > (with support from me and the IAB), created that registry > directly rather than requiring that the IETF establish the > registry and rules for its maintenance. The idea was to try to > help preserve and reinforce the separation implied by the above. > > We've also seen some history of documents being adopted (a > deliberately vague term) in the IETF then being used to argue in > ICANN processes that the IETF action means that ICANN has to > implement then. That approach goes back to at least the CRISP > effort (RFC 3707). That it has been unsuccessful in many cases > is beside the point. That some of the efforts in the IETF have > been strongly influenced by ICANN staff members who might (or > might not) have planned to influence ICANN policy development > processes in ways that they could not do directly may or may not > also be an issue (and you, and other ICANN staff, may reasonably > interpret all of those data differently than I do). > > So the IETF created a WG, LAGER, to do the core work on which > this I-D was based, ultimately cumulating in RFC 7940. I note > that, in recent years, we've had trouble getting enough traction > to do meaningful work on any internationalization (i18n) issues > -- IMO, EAI and PRECIS barely had enough active participation to > justify a claim of meaningful WG consensus by the time their > work wound down and other than a BOF (LUCID) that, IMO, never > engaged with the key topics, the IETF has not been able to > engage on the "non-decomposable character" issue despite a > request from the IAB that it do so. I imagine that many > people, even some of the i18n experts looked at the lAGER > charter and said "if people want to get together and write some > data representation rules around something that is basically an > ICANN problem, I don't need to worry about it". I also > imagine, reinforced by the few comments during IETF Last Call on > what became 7940, that the Last Call reaction was similar. > However, in that case, there _was_ a WG, the IESG reached the > conclusion that the WG had sufficient membership and > participation to be meaningful, and the community generally > assumes that WG conclusions should stand as IETF ones if there > is no meaningful and substantive dissent during Last Call. > > Then the IESG, in its wisdom and for reasons not announced to > the IETF other than "concluded work" (such announcements are > rarely made and I wouldn't propose to change it) closed down the > WG. > > Then this document appears as an individual submission. There > has been little evidence of wide review, especially by those > with significant history of IDN involvement in the IETF. > Perhaps that is in part because it shares the limited scope > issues with LAGER and RFC 7940, requires a thorough > understanding of that document and what it does and does not do, > and, noting that the IAB just shut down its I19n Program after a > long period of inactivity, there seems to be even less ability > to get IETF traction on i18n issues than there was a few years > ago. > > As I understand it, this document provides and explains a system > to assist in developing and describing rules that might then be > documented according to 7940. Even with the latest revision, it > makes some assumptions that some of us (including, given his > comment, I assume Vint) question in an IETF context (even if > they represent ICANN consensus and are reasonable there because > the scope, conditions, and support arrangements are different). > At least in principle, the IESG could have reopened LAGER, > gotten review there, and then pushed this through as a document > from the same WG that was responsible for 7940. They didn't. > > But your conclusion was (out of context, but complete below) > > > There is no IDNA Working Group any more, so there is no way to > > say that it was not endorsed by this WG. The document is, > > however, intending to be an IETF consensus document. > > Right. There is no way to say that LAGER did not endorse it (or > would not have endorsed it had it still existed). Likewise for > IDNABIS. AFAIK, DNSOP and for that matter and, despite it (and > 7940 (to pick a random example) LISP didn't consider it either. > Since 7940 (last paragraph of introduction) and this document > even more strongly claim that their data structures, mechanisms, > and principles can be used for non-DNS identifier labels, > perhaps the latter should have looked at it. But none of them > did although, by your logic as I read it, there is no way to > assume that they would not have endorsed it had they looked and > therefore their assent must be assumed. > > For a claim of IETF consensus on an individual submission, > especially one that is the slightest bit controversial (as this > clearly is, even if one believes the controversy is about > process, not substantive content), I think there has to be clear > evidence of adequate and competent review of document content > and relationship to other work to make that consensus claim > meaningful. I don't think that has been demonstrated; YMMD. > > I also think that, if a document comes out of a WG and then one > of its authors produces a individual document that suggests an > extension, interpretation, or supplemental tools, we need to be > extra-careful about that document and IETF consensus claims. > YMMD about that too. > > Your response to Vint about what can be done about this was: > > > It says "Informational" right at the top of the document, and > > that's the best we can do for the RFC Series. > > But that is not "the best we can do". The IESG can say > "insufficient evidence of IETF consensus" and drop the document. > I don't recommend that, but it is possible that others would > disagree. The document can be handed off to the Independent > Submission Editor with recommendation for publication with the > usual clear statement from that Stream about there being no > consensus assessment. Noting that all of the documents that > started the "variant" epidemic (RFCs 3743, 4290, and, as a key > example at least, 4713) were published in the Independent Stream > and that didn't prevent them from getting community attention, > there is probably little argument for the IETF Stream unless > there is either clear evidence of consensus or if this document > is really expected to be treated as a Standards Track supplement > to 7940 independent of its official status. Or, in principle, > the IESG could attach a note indicating that the document is > published as a convenience and there is little or no evidence of > informed IETF consensus about it. > > For me, it is precisely the claim that the document represents > IETF consensus, or the now-demonstrated high likelihood that > claim will be made, that is the problem here. That claim is, > at best, not demonstrated to be true and, for a document that I > believe lies very close to the boundaries of IETF scope and > relationship to ICANN, I think we need to be extra careful about > it when it is not demonstrably true (and not just because a > series of current and closed WGs haven't commented on, much less > endorsed, it). > > best, > john > > > --------------------------- > > For the information of the IESG and community, Paul forwarded > the Last Call announcement to the idna-update mailing list. > Vint responded there (but not to the IETF list or, AFAIK, to the > IESG) and Paul responded to him (but, again, not to the IETF > list or AFAIK, the IESG). Paul's response to Vint and, IIR, the > substantive part of Vint's message appear below. > > > --On Tuesday, April 18, 2017 09:38 -0700 Paul Hoffman > wrote: > > > On 18 Apr 2017, at 7:04, Vint Cerf wrote: > > > >> if this is published, I hope it is made clear that this is > >> not a standards > >> recommendation endorsed by the IDNA working group. > > > > It says "Informational" right at the top of the document, and > > that's the best we can do for the RFC Series. > > > > There is no IDNA Working Group any more, so there is no way to > > say that it was not endorsed by this WG. The document is, > > however, intending to be an IETF consensus document. > > > > --Paul Hoffman > > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 --001a11c16cc667b0c6054d862c57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1=C2=A0
v


On Wed, Apr 19, 2017 at 9:19 AM, J= ohn C Klensin <klensin@jck.com> wrote:
Paul and IESG,

While I think the clarifications in this draft are a
considerable improvement, your response to Vint captures the
concern about this document all along.=C2=A0 To explain, I'm going to need to review some history, so apologies for probable length.

The whole topic of DNS "variant rules" has been controversial
among those who know about them and care from the beginning.
They are much less so in the context of the root zone for which,
the special names issues aside, ICANN has clear responsibility
(and can make whatever rules they like, including the one to
allow thousands of names, as long as IETF Standards are not
violated -- and even the latter seems to be under threat), than
for zones deeper in the tree and whether such rules are used
there in a voluntary or involuntary.

I note that, at the time ICANN first started allowing and
encouraging IANA publication/ registrations of the characters
that particular TLDs would allow in their zones, the ICANN Board
(with support from me and the IAB), created that registry
directly rather than requiring that the IETF establish the
registry and rules for its maintenance.=C2=A0 The idea was to try to
help preserve and reinforce the separation implied by the above.

We've also seen some history of documents being adopted (a
deliberately vague term) in the IETF then being used to argue in
ICANN processes that the IETF action means that ICANN has to
implement then.=C2=A0 That approach goes back to at least the CRISP
effort (RFC 3707).=C2=A0 =C2=A0That it has been unsuccessful in many cases<= br> is beside the point.=C2=A0 That some of the efforts in the IETF have
been strongly influenced by ICANN staff members who might (or
might not) have planned to influence ICANN policy development
processes in ways that they could not do directly may or may not
also be an issue (and you, and other ICANN staff, may reasonably
interpret all of those data differently than I do).

So the IETF created a WG, LAGER, to do the core work on which
this I-D was based, ultimately cumulating in RFC 7940.=C2=A0 I note
that, in recent years, we've had trouble getting enough traction
to do meaningful work on any internationalization (i18n) issues
-- IMO, EAI and PRECIS barely had enough active participation to
justify a claim of meaningful WG consensus by the time their
work wound down and other than a BOF (LUCID) that, IMO, never
engaged with the key topics, the IETF has not been able to
engage on the "non-decomposable character" issue despite a
request from the IAB that it do so.=C2=A0 =C2=A0I imagine that many
people, even some of the i18n experts looked at the lAGER
charter and said "if people want to get together and write some
data representation rules around something that is basically an
ICANN problem, I don't need to worry about it".=C2=A0 =C2=A0I also=
imagine, reinforced by the few comments during IETF Last Call on
what became 7940, that the Last Call reaction was similar.
However, in that case, there _was_ a WG, the IESG reached the
conclusion that the WG had sufficient membership and
participation to be meaningful, and the community generally
assumes that WG conclusions should stand as IETF ones if there
is no meaningful and substantive dissent during Last Call.

Then the IESG, in its wisdom and for reasons not announced to
the IETF other than "concluded work" (such announcements are
rarely made and I wouldn't propose to change it) closed down the
WG.

Then this document appears as an individual submission.=C2=A0 =C2=A0There has been little evidence of wide review, especially by those
with significant history of IDN involvement in the IETF.
Perhaps that is in part because it shares the limited scope
issues with LAGER and RFC 7940, requires a thorough
understanding of that document and what it does and does not do,
and, noting that the IAB just shut down its I19n Program after a
long period of inactivity, there seems to be even less ability
to get IETF traction on i18n issues than there was a few years
ago.

As I understand it, this document provides and explains a system
to assist in developing and describing rules that might then be
documented according to 7940.=C2=A0 Even with the latest revision, it
makes some assumptions that some of us (including, given his
comment, I assume Vint) question in an IETF context (even if
they represent ICANN consensus and are reasonable there because
the scope, conditions, and support arrangements are different).
At least in principle, the IESG could have reopened LAGER,
gotten review there, and then pushed this through as a document
from the same WG that was responsible for 7940.=C2=A0 They didn't.

But your conclusion was (out of context, but complete below)

> There is no IDNA Working Group any more, so there is no way to
> say that it was not endorsed by this WG. The document is,
> however, intending to be an IETF consensus document.

Right.=C2=A0 There is no way to say that LAGER did not endorse it (o= r
would not have endorsed it had it still existed).=C2=A0 =C2=A0Likewise for<= br> IDNABIS.=C2=A0 AFAIK, DNSOP and for that matter and, despite it (and
7940 (to pick a random example) LISP didn't consider it either.
Since 7940 (last paragraph of introduction) and this document
even more strongly claim that their data structures, mechanisms,
and principles can be used for non-DNS identifier labels,
perhaps the latter should have looked at it.=C2=A0 But none of them
did although, by your logic as I read it, there is no way to
assume that they would not have endorsed it had they looked and
therefore their assent must be assumed.

For a claim of IETF consensus on an individual submission,
especially one that is the slightest bit controversial (as this
clearly is, even if one believes the controversy is about
process, not substantive content), I think there has to be clear
evidence of adequate and competent review of document content
and relationship to other work to make that consensus claim
meaningful.=C2=A0 I don't think that has been demonstrated; YMMD.

I also think that, if a document comes out of a WG and then one
of its authors produces a individual document that suggests an
extension, interpretation, or supplemental tools, we need to be
extra-careful about that document and IETF consensus claims.
YMMD about that too.

Your response to Vint about what can be done about this was:

> It says "Informational" right at the top of the document, an= d
> that's the best we can do for the RFC Series.

But that is not "the best we can do".=C2=A0 =C2=A0The IESG= can say
"insufficient evidence of IETF consensus" and drop the document.<= br> I don't recommend that, but it is possible that others would
disagree.=C2=A0 The document can be handed off to the Independent
Submission Editor with recommendation for publication with the
usual clear statement from that Stream about there being no
consensus assessment.=C2=A0 =C2=A0Noting that all of the documents that
started the "variant" epidemic (RFCs 3743, 4290, and, as a key example at least, 4713) were published in the Independent Stream
and that didn't prevent them from getting community attention,
there is probably little argument for the IETF Stream unless
there is either clear evidence of consensus or if this document
is really expected to be treated as a Standards Track supplement
to 7940 independent of its official status.=C2=A0 =C2=A0Or, in principle, the IESG could attach a note indicating that the document is
published as a convenience and there is little or no evidence of
informed IETF consensus about it.

For me, it is precisely the claim that the document represents
IETF consensus, or the now-demonstrated high likelihood that
claim will be made, that is the problem here.=C2=A0 =C2=A0That claim is, at best, not demonstrated to be true and, for a document that I
believe lies very close to the boundaries of IETF scope and
relationship to ICANN, I think we need to be extra careful about
it when it is not demonstrably true (and not just because a
series of current and closed WGs haven't commented on, much less
endorsed, it).

=C2=A0 =C2=A0best,
=C2=A0 =C2=A0 =C2=A0john


=C2=A0 ---------------------------

For the information of the IESG and community, Paul forwarded
the Last Call announcement to the idna-update mailing list.
Vint responded there (but not to the IETF list or, AFAIK, to the
IESG) and Paul responded to him (but, again, not to the IETF
list or AFAIK, the IESG).=C2=A0 Paul's response to Vint and, IIR, the substantive part of Vint's message appear below.


--On Tuesday, April 18, 2017 09:38 -0700 Paul Hoffman
<paul.hoffman@= vpnc.org> wrote:

> On 18 Apr 2017, at 7:04, Vint Cerf wrote:
>
>> if this is published, I hope it is made clear that this is
>> not a=C2=A0 standards
>> recommendation endorsed by the IDNA working group.
>
> It says "Informational" right at the top of the document, an= d
> that's the best we can do for the RFC Series.
>
> There is no IDNA Working Group any more, so there is no way to
> say that it was not endorsed by this WG. The document is,
> however, intending to be an IETF consensus document.
>
> --Paul Hoffman




--
Ne= w postal address:
Google
1875 Explorer Street, 10th Floor
=
Reston, VA 20190
--001a11c16cc667b0c6054d862c57-- From nobody Wed Apr 19 09:30:05 2017 Return-Path: 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 599CE1300CE for ; Tue, 18 Apr 2017 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xd7m4S-RFcfn for ; Tue, 18 Apr 2017 11:27:08 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374411293E4 for ; Tue, 18 Apr 2017 11:27:08 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id u18so159976wrc.1 for ; Tue, 18 Apr 2017 11:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=7sEukdBS/VEOH1uzyXCmGM+0I1aEOLbhse6M6CHeHXU=; b=Z6urZKIL2gw46XVPW3Fi7kTLMh1dYUd0NQo6jS+YbV7recRerM+9QxHkky53MGtYRu pryDNn5NEl1+kasygJrAh3pdXzK+DzazOFPEpngou2UwUwg4EozjHYuiOc8c+ia3JoDn AvEJ9PkDtp9VPkgK8AJHIPb//jXqizKBMDj/nIIQbFo+TU/kwjOkWpsFnwcWVbRL/njT SMlCZlbrBhxDlNVgPV5sKmGiZFAO3+bjnb6utI/UfH7vDgC3uV6i3nh8zzwIdOwzDbun PaI5eqqEqCXPBhJDo3xh1yrIKwFnnTkQigpUj0QoE1vS2P5juacRN0xh6pCfGncM2lR2 1Z+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=7sEukdBS/VEOH1uzyXCmGM+0I1aEOLbhse6M6CHeHXU=; b=UzQDKK5J9Ghp5JJ7g5/G4Ik5F8zKkt/pkjbjIf7uJ3Dj+kiQtwlwOJjLWLySQGHy7+ 7Lcc01nDPGnKfyQsnp9IrGGTG2Wuqv8DvV5/bg+IXsmswnnmBU6CmSokvC9gLXD/LElU QrqWL247PRIPAkWhwb92UXklz4lgV4eTpcdtve/ffvM+Y8piYFGrkIZ020IsnteoCjmt oItAG3OAf+IhhoEQpg+QHs9JMN7i371XDp8rcSdpS9F4/g7QV381dIiX1BNhJp/LRQQ8 F97mMcSNEzKEIT4FPm6+n/ks1fqS9+WQS0L1/hTMxAd3gUvh4IOVLqjQ5oyFSn8fWI7W Y9LQ== X-Gm-Message-State: AN3rC/60ENoBE5Kqj2qrMKIt9KwaDgaCiHTtP/Zetnyqq5dFB9CJMHbr liNM5Sq3jN985A== X-Received: by 10.223.180.81 with SMTP id v17mr16116090wrd.101.1492540026713; Tue, 18 Apr 2017 11:27:06 -0700 (PDT) Received: from [192.168.1.13] ([197.27.15.15]) by smtp.gmail.com with ESMTPSA id f6sm19707854wrf.13.2017.04.18.11.27.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 11:27:06 -0700 (PDT) Sender: Slim Amamou Date: Tue, 18 Apr 2017 19:26:59 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <4f041d48-b99f-2cc9-f1a2-c93781663743@it.aoyama.ac.jp> References: <7659BFB6-34FE-4C1A-B29B-944C2458333C@gmail.com> <555e150e-9148-0a96-d099-4cc16d6cb40a@ix.netcom.com> <378BDDCE-9BBA-43C5-8916-235237DCD70D@gmail.com> <4D473DC8-02B6-4F26-8085-97C596CF276E@frobbit.se> <4f041d48-b99f-2cc9-f1a2-c93781663743@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: idna-update@ietf.org, =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , Rodger Combs , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Asmus Freytag From: Slim Amamou Message-ID: <5D5BD04C-B0C3-4349-B682-A59F6A64BF88@alixsys.com> Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 09:30:04 -0700 Subject: Re: [Idna-update] Proposal - A new normalization mechanism to protect against confusables 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:27:10 -0000 In arabic it's for both too Le 18 avril 2017 09:50:51 GMT+01:00, "Martin J=2E D=C3=BCrst" a =C3=A9crit : >On 2017/04/18 17:17, Rodger Combs wrote: > >> The only case this would break would be non-malicious registrations >that differ only by combining marks=2E There's a valid debate to be had >over whether or not that's a useful thing to restrict against, but >let's not confuse the issue being discussed there=2E > >I don't know of any actual registered examples, but in the languages=20 >that use accents/diacritics/combining marks, these are usually there to > >make a distinction=2E The distinction can be related to grammar (e=2Eg=2E= =20 >German "Buch" (book) vs=2E "B=C3=BCcher" (books), or it may distinguish >totally=20 >unrelated things (e=2Eg=2E German "Durst" (thirst) vs=2E "D=C3=BCrst" (a = family >name))=2E > >How much is grammar and how much is unrelated stuff will depend on the=20 >language=2E As far as I understand, for Arabic, it's mostly grammar, for= =20 >German, it's both, and for other languages, it may be most if not all=20 >unrelated stuff=2E > >Of course, in no language all the letter combinations are words, and >the=20 >chance to find a minimal pair (a pair of words that differs only in=20 >combining marks) is rather low, in particular if we limit ourselves to=20 >nouns, names, and other things that work in domain names=2E However, >where=20 >there is such a pair, native readers will usually be well aware of it=2E > >Regards, Martin=2E > >_______________________________________________ >IDNA-UPDATE mailing list >IDNA-UPDATE@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/idna-update --=20 Slim Amamou | =D8=B3=D9=84=D9=8A=D9=85 =D8=B9=D9=85=D8=A7=D9=85=D9=88 http://alixsys=2Ecom