[secdir] secdir review of draft-ietf-precis-mappings-11

"Scott G. Kelly" <scott@hyperthought.com> Tue, 04 August 2015 06:06 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 85DDF1B3634 for <secdir@ietfa.amsl.com>; Mon, 3 Aug 2015 23:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lQdi6M0ClsXA for <secdir@ietfa.amsl.com>; Mon, 3 Aug 2015 23:06:48 -0700 (PDT)
Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D251B3632 for <secdir@ietf.org>; Mon, 3 Aug 2015 23:06:48 -0700 (PDT)
Received: from smtp24.relay.iad3a.emailsrvr.com (localhost.localdomain []) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AE84E18022C; Tue, 4 Aug 2015 02:06:47 -0400 (EDT)
Received: from app45.wa-webapps.iad3a (relay-webapps.rsapps.net []) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9E9EF1801CC; Tue, 4 Aug 2015 02:06:47 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from app45.wa-webapps.iad3a (relay-webapps.rsapps.net []) by (trex/5.4.2); Tue, 04 Aug 2015 06:06:47 GMT
Received: from hyperthought.com (localhost.localdomain []) by app45.wa-webapps.iad3a (Postfix) with ESMTP id 8D17E38004A; Tue, 4 Aug 2015 02:06:47 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 3 Aug 2015 23:06:47 -0700 (PDT)
Date: Mon, 3 Aug 2015 23:06:47 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-precis-mappings.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
X-Auth-ID: scott@hyperthought.com
Message-ID: <1438668407.5754864@apps.rackspace.com>
X-Mailer: webmail/11.5.5-RC
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/3M7Kssyxt0bBF6JXdHD7QfUaJfU>
Subject: [secdir] secdir review of draft-ietf-precis-mappings-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 04 Aug 2015 06:06:49 -0000

I have reviewed 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.

The case and width mappings defined in the current PRECIS (Preparation, Enforcement, and Comparison of Internationalized Strings) framework do not handle other mappings (such as delimiter characters, special characters, and locale-dependent or context-dependent case). This short document aims to provide mapping guidelines for PRECIS profile designers.

I think this document is probably ready, but I would raise one question (below) for consideration of those more knowledgeable in this area.

I think the primary security issue with these mappings is that users may misinterpret them (e.g. see "IDN homograph attack" on wikipedia). The security considerations in this document says

   As with Mapping Characters for IDNA2008 [RFC5895], this document
   suggests creating mappings that might cause confusion for some users
   while alleviating confusion in other users.  Such confusion is not
   covered in any depth in this document.

This seems a little terse, but it turns out that it matches the security considerations section of RFC5895 nearly word for word.

My question: should this also include a reference to the security considerations in RFC7564? I leave this to those who know more about 5895, 7564, and PRECIS.