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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5BF512EC30 for <>; Sun, 17 Sep 2017 19:56:11 -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=ThYjY2JN; dkim=pass (2048-bit key) header.b=C5CDLHFq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B8vHOgBUBaBP for <>; Sun, 17 Sep 2017 19:56:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4578126B6E for <>; Sun, 17 Sep 2017 19:56:09 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C799E20852; Sun, 17 Sep 2017 22:56:08 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Sun, 17 Sep 2017 22:56:08 -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=UxCbGQ/mdQ2juWl7yB9ju1RUhQTDu5rcZG9pYX8L6 uk=; b=ThYjY2JNmza2t5wAO2cfoKB5qDyAT8LdJZnKsMqZTwFtf95g7KFJVQLtY hN8wGMShoAn5SrD6x1IIWNWGdu2Lc4OoJj5dUKKvM1m7q4FSds9Q3aAmnQHbcJ2d X7c0Lm8hFrecL6Oaxb9FDEqx+YJ/KEsYKWdWNOYL2D1frRI2vZQQ8OWCY3GWw56Q FrtFb039tGiJxiaLnT1lnRXH0k1Gelwcgyg+56wvYxKYbgVd9I8/UT6Cmsr+Re5P 4c8PhARDoQU01F8trcTTk/HfrOxEejiOqqnCLTvxAP7eBQVLYn/4ESx3EJX/l5fa fFQXnxpwsvkVkSn98eX87wRCZCdBw==
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=UxCbGQ/mdQ2juWl7yB 9ju1RUhQTDu5rcZG9pYX8L6uk=; b=C5CDLHFqQkbU0e2Tu5HOlF+Vh14CI0Gokp k6AwDGKdBE0FiVWqF3M65L3qAwq/tD38ChW8iXh33h+KnvrffAsRIZHbntWP7YEg xKwZwXpPGts+BL3MCm6YDeXqbdsWlSh90YisXxmDNYKR26+/fTcsytGFoEsPxJDI emgaEBlrfqF9WHCDOpIFqaRkase0lVBpxS92C0wllvDyEgmFFZxJtFWSAtSvgnbO Fb6ryJ1J7zgTAcNTbDspZIgebnYANN1Xx317Wsmr4GouSRtX0KcvrFeJo9u1ra1J 8MpjI/VIEO4OIuPS1/4cm24l9yhWr67uxIf5O8SQK+vNDjFTWfxw==
X-ME-Sender: <xms:yDW_Wbcb8M3XODKySyz_fT8tcPnLNqjcj5X_zOiXAHTM3Xhgmu-dYA>
X-Sasl-enc: GO8j5xs1f/p4MNUIM0yYvfGxKg0aEyFNb3S4dAwbsXaj 1505703368
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 1A3CB2460A; Sun, 17 Sep 2017 22:56:08 -0400 (EDT)
To: Sam Whited <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Sun, 17 Sep 2017 20:56:06 -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="2PsneeBfr2w0fVHv7QvJ2IFi7ktsfDx4r"
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 02:56:12 -0000

On 9/17/17 6:37 PM, Sam Whited wrote:
> On Sun, Sep 17, 2017, at 19:02, Peter Saint-Andre wrote:
>> 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.
> I think this is clear enough in the current text. The fact that
> comparisons may fail when I don't expect them to (and that the solution
> is to require multiple expensive iterations) seems like a more
> fundamental class of problem to me though, and not one that can be
> solved by better documenting it.

Well, we can't get something for nothing. Internationalization as
currently designed is expensive in many ways (all those code points to
store client-side, computing-intensive normalization required, potential
for user confusion, potential for attackers taking advantage of a lack
of understanding among developers as in the Spotify story, etc.). The
safest approach is to restrict all protocol slots to ASCII. Fortunately
or unfortunately, in many applications that is deemed unacceptable these
days. However, we don't have to go that far because it's easy to avoid
most of the relevant expenses by using a profile based on the

>> 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.
> I agree that it's less important with the Nickname profile, an issue
> with a profile that was used as an authentication identifier would be
> much worse. The Spotify example was intended more to say "we have seen
> this in the real world, it's not a hypothetical problem" than it was to
> say "this exact thing might happen again".

Sure, I understand. As outlined above, there are difficult tradeoffs
here. We've tried to thread the needle, but perfection is not an option.

>> 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?
> I was under the impression that NFKC was the problem, but that argument
> makes a lot of sense.
>> But I'd argue that modifying the normalization rule of the
>> Nickname profile doesn't really solve the problem, and actually makes it
>> worse.
> I think you're right. My apologies if I misunderstood the problem and
> thought that the solution was to scrap NFKC. 

No need to apologize. This internationalization stuff is complex in a
very messy way. Those darn humans and their langauges... :-)

> There may be other
> solutions, or a depeer underlying problem (the order of operations of
> PRECIS itself was brought up, I think?).

It was indeed. That, however, introduces other issues - we might need to
introduce versioning for PRECIS because a change that deep would really
be PRECIS v2, the existing order of operations was chosen quite
carefully years ago and revisiting that decision would mean rethinking a
lot of how PRECIS works (e.g., interactions between normalization and
width mapping / case mapping) and in the process likely exposing a range
of further isses with particular code points or character categories,
etc. Not to mention that this working group doesn't have the energy or
the authorization (via its charter) to work on PRECIS v2 at this point.

The underlying challenge is again the messy complexity of
internationalization along multiple dimensions - we've tried to do our
best to contain that complexity, but it you push too hard on it from one
direction, it comes bulging out in another direction. There are no
clean, easy, straightforward answers here.

> I don't understand the problem well enough to propose a specific
> solution, I just can't shake the feeling that having a single profile be
> non-idempotent will lead to a serious issue that we're not considering.

I worry about that kind of thing all the time, and not just with
internationalization (personally I still wish we had disallowed wildcard
certs in RFC 6125, but the consensus wasn't with the authors on that
one). But we don't know what the future will bring, and it's difficult
to make decisions based on unshakeable feelings of impending doom.

> Identifiers created with the nickname profile may not be used for
> authentication or authorization, but they will be seen by the users and
> need to be compared in the context of eg. chat rosters, multi-user chat
> participant lists, etc. 

It's true that a nickname / handle / display name is not a solid basis
on which to make authentication or authorization decisions. So don't do
that. :-)

Should we add a sentence about this to 7700bis?

> and developers, in general, won't read
> documentation carefully and are prone to taking the path of least
> resistance; 

Sadly, specifications can't solve the problem of developers taking the
easy route or not understanding the underlying issues.

> we need to make sure the path of least resistance is secure
> and doesn't greatly impact performance (another pressure that will push
> people away from doing the right thing).

The path of least resistance is using ASCII only.

The path of second-least resistance is using the UsernameCaseMapped or
UsernameCasePreserved profile of the IdentifierClass, as we do for
localparts in XMPP.

The path of third-least resistance is using the UsernameCaseMapped or
UsernameCasePreserved profile for authentication or authorization, and
using the Nickname profile only for user-friendly display purposes in
parts of the application or protocol that exist somewhere above that
more solid foundation. (Which is exactly what the WG has produced and
recommended so far.)

Again, if you would like to argue against publishing 7700bis, speak now
or forever hold your peace. You'd be going against the consensus of the
working group (which, after all, did publish RFC 7700 in 2015), so an
Internet-Draft (perhaps entitled "Nickname Profile Considered Harmful")
would be the most effective way to make your case.