Re: [DNSOP] Looking for IANA registry for --xn

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 06 October 2016 17:51 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C353D1293D9 for <dnsop@ietfa.amsl.com>; Thu, 6 Oct 2016 10:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 80lSist7TAAr for <dnsop@ietfa.amsl.com>; Thu, 6 Oct 2016 10:51:49 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 76134129650 for <dnsop@ietf.org>; Thu, 6 Oct 2016 10:51:49 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id i130so20268387wmg.1 for <dnsop@ietf.org>; Thu, 06 Oct 2016 10:51:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TmfNoaIK21L7YKdw3n0EyMwaXUzBb7YFw8xgMDhu69Y=; b=ggkcQITPkij8/Or1X0CP9DUiVilgCFivMkDgsKixBTs7GcDALMIejBDTYxrdB3AyUZ jOOmEIAqh06yT9OEfVMo7n4oZjrMlKPpiJVoyztvnpv3SYfywXWnHjMeHV/deyXufvns ibNqRdONproIFL7T4ooFJqOZ/YkCsfcED3dd6YqrSc4X7i0ePZldt+kPFZZn89u33EKg OKPvGidTj/fvYPDGmD5l1CJ6FkVZw4czFFyoCN3NfdlJP/JcCZoJCWDTPO6uoJzwQNa0 kCtP4VSHSAzTTf1RC/hLu1XzTXxMwdFM++wHOo681LOpcrwSEx/T7wNgwUvK0sgK0wHd mykA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TmfNoaIK21L7YKdw3n0EyMwaXUzBb7YFw8xgMDhu69Y=; b=dWOMb1keR1xEgml/Y6pWlI7YV/1mMY0XD18OEzNn52My1uXZxgL7zg664jRYlP2toO wm0TFAuGV9bHwoSKdm8HY+71mG5l0oQKlyvv0vK0K6S4fZCeEwF5XqsOaOC1Ry67OUtg mddZyTwVwhbP7YDQkdHCBBJ/HeolGYGqyclwjADBoTk3/cb4vzU3j7LA4YYkF4Coa7aL xCdJb/vvG9Zd9w1sIB6XVUTlaJR5bfvOzoTGnVjYJM4mhZJwMr9brKWGtFyMEKREbVWc se2PnsxFlb/oaVENhD9Cv+rie14KJka2Rr3o4ciMn2EuFf55ys2LtmmatScSvGijSH+Z xhtg==
X-Gm-Message-State: AA6/9RlhjwGjihQY/VjpzPJOPDnnJ140tOS8SyypMcn1u9Kh7nFBb9e06enWl0mr4lkb3C4G3TEJS5mu9i91ow==
X-Received: by 10.28.166.205 with SMTP id p196mr22817334wme.21.1475776307782; Thu, 06 Oct 2016 10:51:47 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.167.69 with HTTP; Thu, 6 Oct 2016 10:51:46 -0700 (PDT)
In-Reply-To: <1329930975.314237.1475774676486@mail.yahoo.com>
References: <CAMm+LwjcC6pJ+-LzwGyoG=VVzT_QQ9UrvM3LcZM1121XqCccow@mail.gmail.com> <1329930975.314237.1475774676486@mail.yahoo.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 6 Oct 2016 13:51:46 -0400
X-Google-Sender-Auth: T6GFGkJbrdVn9THiiwNfioCuu8E
Message-ID: <CAMm+LwhnGFR6hqD2PbXyq4OiyLnfAy1K9TbaesmX3A7XVyCiiw@mail.gmail.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Content-Type: multipart/alternative; boundary=94eb2c12cb0a97ead8053e35f210
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zkiZ4q9AkhqIGRNzyNYwUOtViRo>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Harish Chowdhary <harish@nixi.in>
Subject: Re: [DNSOP] Looking for IANA registry for --xn
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2016 17:51:52 -0000

​​


On Thu, Oct 6, 2016 at 1:24 PM, <nalini.elkins@insidethestack.com> wrote:

>
> >I have been looking for the IANA registry in which the IDNA prefix xn--
> is allocated and have not been able to find it. I can see the following
> possibilities
>
> >1) There isn't such a registry. The allocation is purely ad hoc
>
> >2) There is a registry but none of the IDNA RFCs bother to list it as a
> normative reference.
>
> >Either one would be bad. The existence or non existence of a registry,
> the allocation or non allocation of a code point is not going to cause me
> to decide whether or not to use functionality. All that the registry
> achieves is to avoid collisions.
>
> Phil, this is very interesting.
>
> The 'xn--', of course, is the prefix for punycode used for International
> Domain Names.   I have seen it used for DNS resolution quite a bit in the
> last couple of months.   So, it is certainly used.   In fact, that appears
> to be the only way one can do DNS resolution (at least in my experience).
> That is, do the translation from IDN to punycode.   Then, it seems to work
> like a charm.
>
>
​I am not looking to extend the xn-- system, I have another parallel
application.​

Imagine for the sake of argument that someone who was a VIP (VERY VIP)
needed a secure email system and imagine that they wanted something that
was completely compatible with the existing email infrastructure. ​


​A UDF fingerprint MAY be encoded as a DNS label by prefixing the Base32
text representation with the string ‘zz--‘.

A DNS name that includes a UDF fingerprint as a DNS label carries the
implicit assertion that the interpretation of the address MUST be
authorized by a security policy that is validated under a key that matches
the corresponding fingerprint.


Placing such a DNS label as the top level (rightmost) label in a DNS
address creates an address that is not legal and thus cannot be resolved by
the Internet DNS infrastructure. Thus ensuring that the address is rejected
by applications that are not capable of performing the associated
validation steps.


For example, Alice has the email security key with fingerprint
MB2GK-6DUF5-YGYYL-JNY5E. She uses the following email addresses:

​* ​
alice@example.com

Alice publishes this email address when she does not want the other party
to use the secure email system.

​* ​
alice@zz--mb2gk-6duf5-ygyyl-jny5e.example.com

Alice publishes this email address when she wants to give the other party
the option of using secure email if their system supports it.

The DNS server for example.com has been configured to redirect requests to
resolve zz--mb2gk-6duf5-ygyyl-jny5e.example.com to the mail server
example.com.

​* ​
alice@example.com.zz--mb2gk-6duf5-ygyyl-jny5e

Alice uses this email address when she wants the other party to be able to
send her email if and only if their client supports use of the secure
messaging system.

While there should never be a DNS label of the form zz--* in the
authoritative DNS root, such labels MAY be introduced by a trusted local
resolver. This would allow attempts at making an untrusted communication
request to be transparently redirected through a locally trusted security
enhancing proxy.​