Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

Peter Saint-Andre <> Mon, 18 September 2017 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6D131320DC for <>; Sun, 17 Sep 2017 17:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Tez29TP2; dkim=pass (2048-bit key) header.b=LcB0dBZD
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5vIbhT0WqUfX for <>; Sun, 17 Sep 2017 17:02:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2102126E64 for <>; Sun, 17 Sep 2017 17:02:36 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1EBBC2090D; Sun, 17 Sep 2017 20:02:36 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 20:02:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=ioNegREv2Uvr2fDtTOFXIYx2/fLjX34rK5WgRFw30 mc=; b=Tez29TP2eXhDvQVA8Mch3Xgi9zpAuga4DWoHVbF5iXmbAElMMh56rfmXh nezB9ldojbdO8Bhc08YLwBAsXrVoSDUSu4Xl7Pd0vT1Mcd0gykU9wQibbYS5tgnC ERkXwEN6RT/d1I4HOHSS4sA/sOBM4gBOYVO0ojgeDviX0eM8vMBrBAxssbOkaztw pI/CMLTKW9z2Gt9cZTnVSyQxgj2FVi4vwON40MOuMS8zG+eh/XL94KsPxr8/3YkS infjcYJzW8ERFdAQ1cki/rWhFoMmHQ2BADdnFnhgdU1OX70V7Han9ejpGPBIJPw6 8W9bMmugrMtQ5O0NcmEQZn68Zq7+w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ioNegREv2Uvr2fDtTO FXIYx2/fLjX34rK5WgRFw30mc=; b=LcB0dBZDOErhpsECJcKxwogZlMbbLuWc9m XOkGnffn97fh8egTf6K8NP9Bq1vP3wfGkGjwLgGwWaqmeyCU/hc5wmkiME0ASjJ+ hf/m5uFJpBEpCpqaIiJoGEnaMWTkS8y4tPRDAehe9zGTdUKvNE2BcVi4HoR1K+Yu DGOxrVfQFUlmiLOOWleeC8isrXKfqSzWqn0DmK6JepnSTVhZ4/ziiBzfgfXtMMHe K930p3gPZQKdQZFY4lX7TRJ/FGUlL1mpu1LqZZzvx5iIQIPbR8hlnkxsZhjBT0lU +kVS7Yiqaygjb23CmogO1r/Hm0wSDOxPOrOmn6kwa3f8L+h8AWrQ==
X-ME-Sender: <xms:HA2_WecVUIb2qkUhxo1P09EKDTXDUTflj6bY4d3O9CRad8dg18TJrA>
X-Sasl-enc: lTtLq6vIudw/lvJChbThaC4aStaYjcnRHmNqeANJn7db 1505692955
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 7BC492489E; Sun, 17 Sep 2017 20:02:35 -0400 (EDT)
To: Sam Whited <>
References: <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Sun, 17 Sep 2017 18:02:34 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ei9bIaraGbfPTpLQOoaK5Cb2qfqUb61iA"
Archived-At: <>
Subject: Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Sep 2017 00:02:39 -0000

On 9/17/17 2:51 PM, Sam Whited wrote:
> On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote:
>> Why would an application need to care about this? This is an internal
>> implementation detail of a PRECIS library/API, and IMHO it would be
>> irresponsible of the library/API author to offer an option for
>> application developers to select how many times to apply the rules.
> That's fair, but in that case this specific profile is a special case
> that takes a massive performance penalty even when it doesn't need too
> (if the library author did this at all).
> My point is that we can't count on this, and there are still opinions
> and if's in that statement. We should be trying to make this as secure
> as possible at the spec level; regardless of what we feel might be more
> important, if it's easier to not do this, or it incurs a big performance
> penalty to do it some library authors probably won't.
>> Sam, I am going to reiterate that we are EXTREMELY close to publication
>> of this document - it could have happened on, say, Thursday morning
>> right before you posted to the list about this. Please please please
>> either propose very specific text or point to an earlier email message
>> where you did so, because personally I have forgotten if you already did
>> that and my recollection from the previous discussion was that you did
>> not raise objections to the compromise text that Bill Fisher and I
>> agreed on. If your proposal is that we make significant changes to the
>> document at this time, then the Working Group chair or Area Director
>> will likely have to suggest a path forward, because your feedback is
>> coming so very late in the process.
> I don't have a specific solution; I understand that this would require
> reworking the Nickname profile to not use NFKD which is a huge change,
> and that's unfortunate, but I still do not beleive it's appropriate to
> publish this document in its current form. I voiced this opinion early
> on, and the compormise change did nothing to address it, so I did not
> voice it again at that time, maybe I should hvae. I am voicing the
> feedback again now because I think the spotify article is better
> evidence that this is a real problem than I had before.

Sam, I've had a chance to think about this a bit more and I would like
to point out a few additional aspects of the issue you've raised.

First, the Nickname profile is based on the Freeform Class. As we know,
this in itself is a dangerous move. If you want safety and security, you
really really really need to use a profile based on the IdentifierClass.
We have emphasized this many times and it is clearly expressed in the
various PRECIS specs. If we need to add more warning text to 7700bis,
I'd be happy to do that.

Second, we have make this dangerous move for the sake of greater
expressiveness in situations where, in essence, it doesn't matter very
much. For instance, in XMPP all authorization and authentication
decisions are based on a user's Jabber ID (of which the localpart is an
instance of the UsernameCaseMapped profile of the IdentifierClass),
i.e., on a much safer construct than a user's nickname. Other uses for
the Nickname profile might be as petnames for things like user-visible
bookmarks - i.e., for things that are not shared across multiple users,
used for inter-user communication, or relied upon for authetication or
authorization. So I think the scope and implications of the issue you
have raised are much more limited than those we can directly derive from
the Spotify story.

Third, in Section 2.1 of 7700bis we've explained the reasoning behind
using NFKC instead of NFC:

   4.  Normalization Rule: Apply Unicode Normalization Form KC.  Because
       NFKC is more "aggressive" in finding matches than other
       normalization forms (in the terminology of Unicode, it performs
       both canonical and compatibility decomposition before recomposing
       code points), this rule helps to reduce the possibility of
       confusion by increasing the number of code points that would
       match (e.g., U+2163 ROMAN NUMERAL FOUR would match the
       combination of U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN

Your proposal to scrap NFKC in favor of NFC would actually make things
worse here, because matching would be more lax. As a result, users would
be more confused and attackers could more easily impersonate legitimate
users. Is that what we want?

We're trying to strike a delicate balance here between safety and
expressiveness. The Nickname profile gives developers a very pretty gun
that allows them to shoot themselves in the foot. In some restricted
settings, where it doesn't really matter, the Working Group has made the
judgment that this is OK. If you are indeed deeply concerned about the
security implications of any use of the Nickname profile in Internet
applications, then it would be better to argue that it should not be
published in any form - or, at the least, that it needs to contain more
warning text. But I'd argue that modifying the normalization rule of the
Nickname profile doesn't really solve the problem, and actually makes it