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

Paul Hoffman <phoffman@imc.org> Mon, 05 October 2009 21:07 UTC

Return-Path: <phoffman@imc.org>
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 17EA028C20B for <secdir@core3.amsl.com>; Mon, 5 Oct 2009 14:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.644
X-Spam-Level:
X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 DpIkmmqk0nYv for <secdir@core3.amsl.com>; Mon, 5 Oct 2009 14:07:46 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 71E6F3A67E4 for <secdir@ietf.org>; Mon, 5 Oct 2009 14:07:42 -0700 (PDT)
Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n95L9GLu049821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 14:09:17 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240883c6f00ff718bf@[10.20.30.163]>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B091208282265@TK5EX14MBXC115.redmond.corp.micr osoft.com>
References: <D80EDFF2AD83E648BD1164257B9B091208282265@TK5EX14MBXC115.redmond.corp.micr osoft.com>
Date: Mon, 05 Oct 2009 14:08:31 -0700
To: Charlie Kaufman <charliek@microsoft.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "john+ietf@jck.com" <john+ietf@jck.com>, "vint@google.com" <vint@google.com>, "d3e3e3@gmail.com" <d3e3e3@gmail.com>, "idna-update@alvestrand.no" <idna-update@alvestrand.no>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
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: Mon, 05 Oct 2009 21:07:47 -0000

At 8:35 PM +0000 10/5/09, Charlie Kaufman wrote:
>I would question one statement in the document.
> 
>From Section 8.2:
> 
>In the presence of DNSSEC, no form of a zone file or query response that contains a U-label may be signed or the signature validated.
> 
>[a U-label indicates a name form containing non-ASCII characters not properly encoded with IDN].
> 
>I would expect that DNSSEC would operate at the layer below IDN, and could therefore sign and validate any data that DNS could validly return. There may be subtle reason for this restriction that I don't understand, but the justification in the document didn't seem right.

Note that the sentences before the one that you flagged are:

   IDNA specifies that all internationalized domain names served by DNS
   servers that cannot be represented directly in ASCII MUST use the
   A-label form.  Conversion to A-labels MUST be performed prior to a
   zone being signed by the private key for that zone.  Because of this
   ordering, it is important to recognize that DNSSEC authenticates a
   domain name containing A-labels or conventional LDH-labels, not
   U-labels. 

The sentence that you flagged is just plain confusing and can be elided without loss of value to the document.