Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt
John C Klensin <klensin@jck.com> Tue, 06 October 2009 00:15 UTC
Return-Path: <klensin@jck.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 193AA3A67B3; Mon, 5 Oct 2009 17:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 EQAYy0KHc06m; Mon, 5 Oct 2009 17:15:14 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B07D53A68B3; Mon, 5 Oct 2009 17:15:13 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MuxjP-0006bO-0t; Mon, 05 Oct 2009 20:16:43 -0400
Date: Mon, 05 Oct 2009 20:16:41 -0400
From: John C Klensin <klensin@jck.com>
To: Charlie Kaufman <charliek@microsoft.com>, Paul Hoffman <phoffman@imc.org>, secdir@ietf.org, iesg@ietf.org, vint@google.com, d3e3e3@gmail.com, idna-update@alvestrand.no
Message-ID: <17823AE7FE62B8814BE101BF@PST.JCK.COM>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B091208283635@TK5EX14MBXC115.redmond.corp.microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B091208282265@TK5EX14MBXC115.redmond.corp.micr osoft.com> <p06240883c6f00ff718bf@[10.20.30.163]> <D80EDFF2AD83E648BD1164257B9B091208283635@TK5EX14MBXC115.redmond.corp.microsoft.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-Mailman-Approved-At: Mon, 05 Oct 2009 22:48:14 -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 00:15:15 -0000
--On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman <charliek@microsoft.com> wrote: > I considered putting in more context, but decided against it > (clearly a mistake). > > IDNA specifies that all internationalized domain names served > by DNS use the IDNA encoding, but the DNS spec does not. So > the full statement in the draft appears to be saying that a > DNS zone that does not use IDNA cannot use DNSSEC (in the > sense of it wouldn't work as opposed to it MUST NOT). I cannot > figure out why that would be true, though as I said there may > be some subtlety I'm missing. I agree with Andrew that I can't > see why this document should mention DNSSEC at all. Charlie, Thanks for the careful reading. Let me respond as holder of the pen (but one who has put a lot of stuff into the document because the WG apparently wanted it rather than because I was convinced it was necessary). There are at least two things going on here: (1) As a collection, the IDNA documents have a number of requirements that are (or should be) stated as "if you sign up for IDNA, then you are required to behave this way". If anything appears to impose requirements on DNS implementations, zones, or other features except in that "conforming to IDNA" context, then it is unintended and almost certainly needs to be fixed. Sometimes that constraint is present in order to make sure that future extensions that use a "this prefix means something special" can occur without causing problems for IDNA or being mutually exclusive, rather than because of an immediate need of IDNA as reflected in this set of documents. However, it turns out to be harder to impose and describe those constraints than one might expect, so some of the instances of it may be convoluted. That said, IDNA cannot impose constraints on binary labels used in non-IDNA-aware implementations. It has been clear since the dawn of the DNS, and certainly since RFC 2181, that arbitrary octet strings are permitted to appear in zones and in queries. Such octet strings can certainly be UTF-8 or ISO 8859-1; they can even be, e.g., UTF-16 (UCS-2) in spite of the chaos that would cause for applications that assumed they could use null octets as string terminators without being careful about it. However, whatever such labels might be, they aren't IDNA-conformant IDNs or, as far as IETF Standards are concerned, IDNs at all. (2) As far as DNSSEC is concerned, you are quite correct: nothing in IDNA has anything to do with it. The text is there for two reasons: (i) Someone thought it important enough to mention and insisted that we do so. It wasn't me. (ii) The "two (or more) representations of the same logical label" design that underlies IDNA (both the new version and the old one) creates some odd ambiguities with regard to many protocols and namespaces (see draft-iab-idn-encoding for an evolving discussion of some of those issues). In some cases, one pretty much has to use the A-label (ACE-encoded) form. In others, the U-label (native Unicode characters) form is anticipated and required. Still others may be flexible. When I discussed IDNABIS at a SAAG meeting some time ago, I was treated to an extended discussion (during and after the meeting itself) about whether certificates and other credentials should keep and interpret information in ACE (A-label) form or as native-character Unicode strings and about the importance of being able to convert from dot-separated labels to length-label pair form other than as part of calls to the DNS because some credentials were kept in the latter form. At least for a while, some of us anticipated DNS servers that would accept zone files with IDNs in U-label form as input and automagically do the conversion to A-labels, presumably performing IDNA validation as part of that process. Is it desirable in that context to say "don't even think about computing DNSSEC values on anything but the A-label" or "because the A-label is the only thing an IDNA-conforming program can put in, or look up in, a zone, DNSSEC is not affected"? I really don't know... and am certainly happy to make whatever changes in those explanations that the community thinks appropriate. john
- [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