Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt

JFC Morfin <jefsey@jefsey.com> Tue, 06 October 2009 11:02 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5623A68DA; Tue, 6 Oct 2009 04:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.484
X-Spam-Level:
X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSNSk-Lt7eZl; Tue, 6 Oct 2009 04:02:39 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 2C9AB3A67EA; Tue, 6 Oct 2009 04:02:39 -0700 (PDT)
Received: from 89-158-60-18.rev.dartybox.com ([89.158.60.18]:1438 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1Mv7pw-0002gO-Gm; Tue, 06 Oct 2009 04:04:08 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 06 Oct 2009 13:04:04 +0200
To: Charlie Kaufman <charliek@microsoft.com>, John C Klensin <klensin@jck.com>, Paul Hoffman <phoffman@imc.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "vint@google.com" <vint@google.com>, "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "idna-update@alvestrand.no" <idna-update@alvestrand.no>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B0912082837C2@TK5EX14MBXC115.re dmond.corp.microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B091208282265@TK5EX14MBXC115.redmond.corp.micr osoft.com> <p06240883c6f00ff718bf@[10.20.30.163]> <D80EDFF2AD83E648BD1164257B9B091208283635@TK5EX14MBXC115.redmond.corp.microsoft.com> <17823AE7FE62B8814BE101BF@PST.JCK.COM> <D80EDFF2AD83E648BD1164257B9B0912082837C2@TK5EX14MBXC115.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage2.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20091006110239.2C9AB3A67EA@core3.amsl.com>
X-Mailman-Approved-At: Tue, 06 Oct 2009 07:39:04 -0700
Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2009 11:02:40 -0000

At 09:33 06/10/2009, Charlie Kaufman wrote:
>My reading of the IDNA spec was that no query response would ever 
>contain a U-label, and therefore saying that if the query response 
>did contain a U-label then DNSSEC couldn't sign or verify it seems 
>nonsensical. I believe that DNSSEC is more like part of DNS than up 
>at the layer of IDNA; it can sign anything that DNS can return.
>
>I believe the DNSSEC spec says that what is signed is the "wire 
>form" of the name, which should be unambiguous unless different wire 
>forms are used in different contexts in the DNS protocol. For DNS 
>servers following IDNA, the wire form would always be an A-label or 
>an LDH-label.
>
>I could easily believe that there are problems when DNSSEC interacts 
>with non-IDNA compliant names (either because the term "wire form" 
>was ambiguous in some contexts or because the DNSSEC spec did not 
>consistently use that terminology). But I haven't heard anyone claim that yet.


Charlie,

the debate over IDNA has lasted many years. During that many years 
some "WG IDNA culture" developped with its own terminology. In turn 
that terminology evolved as the consensus developped. It makes things 
more difficult to grasp for outsiders like you and us ("contributing 
users" coming from the outer world, I had to teach). Our user's point 
of view may help you figuring things out (they are discussed in 
http://tools.ietf.org/html/draft-iucg-punyplus-02). Basically we 
consider a naming pile wich includes three layers. We name them:

* UDN - as User Domain Names (in UTF), to be converted back/forth. 
This is what the user types and see.
* ADN - as Application Domain Names (in the way application wants 
them), to be converted back/forth. This is what is really used by 
non-Internet IDNA limited applications and non-internet protocols 
(hoppefully stripped from non permitted chars if they want to be 
Internet DNS interoperable)
* IDN - as Internet Domain Names (in what you call "wire form", i.e. 
strict Internet DNS names). DNSSEC fully applies on them. They result 
from the punycode encoding.

To understand why this three layer pile is the easiest want to 
understand the whole system:
- if fully respects the fundamental target to keep the DNS unaffected
- the UDN layer (therefore the unchanged DNS layer) can fully support 
any cross-technology Semantic Addressing System without the need to 
encapsualte the DNS. DNSSEC and other discussed security oriented 
possibilities are unaffected.
- user can directly type ADNs (what is named U-labels) or IDNs (what 
is named A-labels).
- security issues can be reduced to simpler layer localized considerations.

The only remaining problems are that the entire process is not end to 
end because upper-cases are not restored on the other end (what the 
punycode algorithm is now prevented to do for good reasons) and 
cannot be considered for DNS resolutions. Punyplus will address these 
two problems in a simple and robust way as an IDNA added value, once 
IDNA is published.

Best

jfc