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
- [secdir] secdir review of draft-ietf-idnabis-rati… Charlie Kaufman
- Re: [secdir] secdir review of draft-ietf-idnabis-… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-idnabis-… Paul Hoffman
- Re: [secdir] secdir review of draft-ietf-idnabis-… Charlie Kaufman
- Re: [secdir] secdir review of draft-ietf-idnabis-… Martin J. Dürst
- Re: [secdir] secdir review of draft-ietf-idnabis-… Vint Cerf
- Re: [secdir] secdir review of draft-ietf-idnabis-… John C Klensin
- Re: [secdir] secdir review of draft-ietf-idnabis-… John C Klensin
- Re: [secdir] secdir review of draft-ietf-idnabis-… Charlie Kaufman
- Re: [secdir] secdir review of draft-ietf-idnabis-… Vint Cerf
- Re: [secdir] secdir review of draft-ietf-idnabis-… John C Klensin
- Re: [secdir] secdir review of draft-ietf-idnabis-… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-idnabis-… John C Klensin
- Re: [secdir] secdir review of draft-ietf-idnabis-… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-idnabis-… JFC Morfin
- Re: [secdir] secdir review of draft-ietf-idnabis-… John C Klensin
- Re: [secdir] secdir review of draft-ietf-idnabis-… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-idnabis-… Eric Brunner-Williams
- Re: [secdir] secdir review of draft-ietf-idnabis-… Paul Hoffman
- Re: [secdir] secdir review of draft-ietf-idnabis-… Elisabeth Blanconil