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

Sam Whited <> Mon, 18 September 2017 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E1CB132C2A for <>; Sun, 17 Sep 2017 17:37:26 -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=hoGLgL7H; dkim=pass (2048-bit key) header.b=a63UsAMM
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSRy4LIoSlY3 for <>; Sun, 17 Sep 2017 17:37:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32A6513243A for <>; Sun, 17 Sep 2017 17:37:25 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 356E620C3E; Sun, 17 Sep 2017 20:37:24 -0400 (EDT)
Received: from web3 ([]) by compute4.internal (MEProxy); Sun, 17 Sep 2017 20:37:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pjWarFroiNVDFW+en nFBVf3QjBA6/4HeRm918N3DfJI=; b=hoGLgL7HZA5SXDhF78C8oBJO4YMrPohGl dOxCTxZPDt1gvb4WH6qoj4OZCtUeCiUOzPHZrlOGN+OcDcxXSTVUjdn0f7/tbzPg 8qZHAZgEzTp0dxUCx0XWRLPWMbAGM5scDSIKIGMF6RjPvPh4KOlm4vfE7q3oIuCK orQYAP3Z6Rr6G9hggoaEZllqLv9dehnRjTqhr+l/PekSk7+Gv+KQMPxFq2cwURPM xv0CuXrvxSKM6XDFMu5LRLUWj1H/KrLVroF3NZXl59WnvFZoMyrg5QMLnDsPsVrw V1kMeRmfrjJp2uKwLeMAGPtB06ZcAY534QI8B5qKE9657jDW2oWeQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pjWarF roiNVDFW+ennFBVf3QjBA6/4HeRm918N3DfJI=; b=a63UsAMMKPDMCaZOMbBc7v 6pa93ngB6S9ZhoYEDiKYdG9ZaSjrO3LTreU2xRD9SB0a/gI8XKv40+AsZBbu6BFw 3SDGDEJ+PKnPNfwnx3Jc/SK6ii9URGLYMZ7xfSuPp/JDrCJwMkuTP+yUmJKf3spp sGzoBRRa8R7Nn+2UktHkeTZPuZqkbEM30nquURoWtiGp8scrzGbbtWInk4BvIBay 4AHO6jjUXfrZgz3Qcab5digGmh4QsAgX5bDFqqdot3PsR4oahMecG2ME9ufHxplJ NaF2trh/f1PJsFE0OAMZbFl+7s0GWVFaHN3AfH+SkD49cz02uReMF7LRirUf4FEw ==
X-ME-Sender: <xms:RBW_WYaXVVLGDDO34bx2XGKkTz7fQTn308dkDOx2nz9OB1nVaqMj-w>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 06A7C9EB1B; Sun, 17 Sep 2017 20:37:23 -0400 (EDT)
Message-Id: <>
From: Sam Whited <>
To: "Peter Saint-Andre" <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-64b08692
Date: Sun, 17 Sep 2017 19:37:23 -0500
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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:37:26 -0000

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.

> 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".

> 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. There may be other
solutions, or a depeer underlying problem (the order of operations of
PRECIS itself was brought up, I think?).

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.
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. and developers, in general, won't read
documentation carefully and are prone to taking the path of least
resistance; 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).