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

Charlie Kaufman <charliek@microsoft.com> Mon, 05 October 2009 20:33 UTC

Return-Path: <charliek@microsoft.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 74C6B3A6985; Mon, 5 Oct 2009 13:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 BiW+DEkW9A1N; Mon, 5 Oct 2009 13:33:35 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C5B803A6A35; Mon, 5 Oct 2009 13:33:35 -0700 (PDT)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 13:35:15 -0700
Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.58]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Mon, 5 Oct 2009 13:35:08 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "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>
Thread-Topic: secdir review of draft-ietf-idnabis-rationale-13.txt
Thread-Index: AcpF+1K5weWnWdVzQdy31RKVnjmSPA==
Date: Mon, 05 Oct 2009 20:35:06 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B091208282265@TK5EX14MBXC115.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_"
MIME-Version: 1.0
Subject: [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 20:33:38 -0000

I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.

This I-D is part of a set of I-D's that update the RFCs on Internationalized Domain Names. This document is intended to become an Informational RFC and provides a rationale for the proposed changes (as well as for the initial design of IDNA). Its Security Considerations section defers to draft-ietf-idnabis-defs-11.txt, which has a good Security Considerations section.

In my opinion, the change to IDNs that warrants the most concern is the fact that for some IDNs the new set of RFCs will specify a different representation than the old one did. This could in theory cause security problems, though that seems intuitively unlikely (to me, at least).

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.

                --Charlie