Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

John C Klensin <john-ietf@jck.com> Mon, 12 January 2015 15:39 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECAA1AC3D5; Mon, 12 Jan 2015 07:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZKtcw-7IpoZ; Mon, 12 Jan 2015 07:39:10 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6E61AC3B1; Mon, 12 Jan 2015 07:39:10 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YAh53-0007gs-65; Mon, 12 Jan 2015 10:39:01 -0500
Date: Mon, 12 Jan 2015 10:38:56 -0500
From: John C Klensin <john-ietf@jck.com>
To: Randy Bush <randy@psg.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
Message-ID: <093CDA9253B966EE8D1304C1@JcK-HP8200.jck.com>
In-Reply-To: <m2k30smlys.wl%randy@psg.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <m2k30smlys.wl%randy@psg.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-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/-Ur59We404o4_sxT7chS4nEBjq0>
Cc: IETF Disgust <ietf@ietf.org>, saag <saag@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 15:39:13 -0000


--On Monday, January 12, 2015 09:39 +0100 Randy Bush
<randy@psg.com> wrote:

>> I'd go even further than that and just mandate MUST ASCII.
>> This is a simple means of pointing to a PKCS #11 object, not
>> a universal means of communicating abstract concepts in any
>> language known to man.  We've already gone from "specify a
>> path to load a PKCS #11 module" to something that's fast
>> heading towards being Turing-complete, if it isn't already
> 
> can you say "attack surface?"
> 
> http://www.cs.dartmouth.edu/~sergey/langsec/

Randy,

As I'm certain you know but others reading this probably don't,
this is symptomatic of an extremely general problem with i18n.
As with "more security" or "more privacy", "internationalization
good, ASCII-only bad" can easily pass from a legitimate and
important issue and goal into slogans and political correctness.
The problem is almost identical to the security one: doing
things well is hard, retrofitting into something that wasn't
designed with security/i18n in mind is _much_ harder, and there
is a permanent shortage of both pixie dust and magical
invocations with sufficient power to solve the problems.

As with protocols designed without security, taking something
that was designed for ASCII and with no thought for i18n issues,
either becomes a matter of very careful analysis or, as you
suggest, crude efforts to retrofit something don't solve the
i18n problems and, as you point out, often broaden the attack
surface.  We really need to get better at asking whether a given
piece of protocol actually needs characters outside the ASCII
repertoire and, if it does, to find the expertise and make the
investments needed to get it right.

Security-related protocols that increase the security risks,
whether in the name of i18n or something else, do not appear to
me to be the way we should be going.

It is clear to me that investment hasn't been made here.  It is
almost as clear that the problem lies with the PKCS specs and
not with this particular document.    What to do about it is
another matter, but it seems to me that "ASCII only until
PKCS#11 itself is adequately revised" is a plausible possibility.

best,
    john