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

Donald Eastlake <d3e3e3@gmail.com> Thu, 06 October 2016 17:59 UTC

Return-Path: <d3e3e3@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 B5F4F129745 for <dnsop@ietfa.amsl.com>; Thu, 6 Oct 2016 10:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 5a6POYTIqBNz for <dnsop@ietfa.amsl.com>; Thu, 6 Oct 2016 10:59:41 -0700 (PDT)
Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::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 4027512973F for <dnsop@ietf.org>; Thu, 6 Oct 2016 10:59:41 -0700 (PDT)
Received: by mail-vk0-x243.google.com with SMTP id z126so1018834vkd.0 for <dnsop@ietf.org>; Thu, 06 Oct 2016 10:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B18/iEY89HXEZKh36Pi6Vf+lSXYr7hlwUvTKZtcbPqQ=; b=0M/emM4tM2iwRFE9CCscVmml4FyFrYbvU8pICjrrBTfHxZgYOi66wNaf5GzdRApkP0 ZXWBfrAdP1YlO2VlCWa2pEiBU6m2r5eG4KQuL6CEMsi7h6VtioipJnMi5OyOP9oYs/Ub 6ONzKwKMqqDLkrb7Ho1GfquVAbCfOxRF5LpAwvdvoS5ezJaEveDBMlIEWpu4TJsCMQNQ jKaSztuucjq26lGaOcLlPqZU2+trg6DyySk4rK7r2SGJz16z9h2mQKM3slCwn3AvAdwM UFeZGPquXosvGWNFht2uyypknrT3T4mhV8cVOctgWgQt9T+sSoZ9niqMqoFNs01ad2Qx U4Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B18/iEY89HXEZKh36Pi6Vf+lSXYr7hlwUvTKZtcbPqQ=; b=dNK/vNzsaeNQxx9Ada5vceWv4dMf6BoBvBrwtJzRtQpEStfuhrDrIlADH12OHTEkF1 bnffq9xgMSZBN1OwqWxrJ4KWETzSFjNGnrFUlG5VsrsvwaurhVSCL6IPIRWtBKM3UHT0 gaG0OMC7Q+ysn2P8FjwmNmpTK6k940cV9VAxPRG0SJjsTyVtJug+ONSdhX80wzPv7GXy sR3/stzfj1XKFo13+3WDxE1XRfjbvJeYrf8T8iJg0pgrIumPF+Y0dWA8v1NpgnTJVILW K3PB9rzqsHsjASRDm/EIJk6u8w5t8C9Ouspg2QsdlE4YG2dbZwnDm0Id787/GCXKNnct IFEw==
X-Gm-Message-State: AA6/9RkFOyFlhOFzcv2dvLR9Nb9PJq3r9mSzOqD44vjo+NYZBcgswflIiIbWYG9ga9ajJwu7SoP/IKOGdkxYGQ==
X-Received: by 10.31.157.201 with SMTP id g192mr11796621vke.85.1475776780288; Thu, 06 Oct 2016 10:59:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.64.199 with HTTP; Thu, 6 Oct 2016 10:59:24 -0700 (PDT)
In-Reply-To: <CAMm+LwhnGFR6hqD2PbXyq4OiyLnfAy1K9TbaesmX3A7XVyCiiw@mail.gmail.com>
References: <CAMm+LwjcC6pJ+-LzwGyoG=VVzT_QQ9UrvM3LcZM1121XqCccow@mail.gmail.com> <1329930975.314237.1475774676486@mail.yahoo.com> <CAMm+LwhnGFR6hqD2PbXyq4OiyLnfAy1K9TbaesmX3A7XVyCiiw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 6 Oct 2016 13:59:24 -0400
Message-ID: <CAF4+nEGg9zGNzUkGz2_NgrxJnia7Wax6i_f3B-VNZw+1=KAEnA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary=001a114158fec1c9ce053e360e88
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v5Eff8xSwDmX4EN6LhWjXgn6Nvg>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Harish Chowdhary <harish@nixi.in>, Nalini Elkins <nalini.elkins@insidethestack.com>
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:59:44 -0000

I don't believe there is a registry. It would seem reasonable to reserve
labels starting with all other [a-z][a-z]-- besides xn-- and establish a
registry. (To avoid people trying to squat on names in advance, the "xn"
was selected by the same sort of publicly verifiable random process as
nomcom voter selection.) Especially if there are any other DNS parameter
registration things that need to be tweaked, I think the best thing might
be an update of RFC 6895.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Oct 6, 2016 at 1:51 PM, Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

> ​​
>
>
> 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.​
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>