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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BDA9132F69 for <>; Mon, 18 Sep 2017 16:18:20 -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=EUtlydoP; dkim=pass (2048-bit key) header.b=Xi1bJ/H2
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OiNJJ5QaYB-7 for <>; Mon, 18 Sep 2017 16:18:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CFDA132076 for <>; Mon, 18 Sep 2017 16:18:17 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 3D1D920BE4; Mon, 18 Sep 2017 19:18:17 -0400 (EDT)
Received: from frontend1 ([]) by compute2.internal (MEProxy); Mon, 18 Sep 2017 19:18:17 -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=Z+IGzflgxcEqhpVAcjoX+lbuiO/CmQStIzyn5v7in YE=; b=EUtlydoPRJ9oFFJW9dEm8ydZcQOgCUIOUUai9zra4tywizMFSPGEBvhzi FK4PkVM2MNvhcsZW4+bbzlXVHei9hWExDLU6q33Gv6R99rF2BrOmPXs0WhKMM/3i iuOWLEJdY3M9KZHJir+S1FMrXpCvejcMRDXMruDFrmP26r/IEDn/Xg/PS3zugxUA OOQ1qoryhaqD/MsMq+vswURih8gZHjb7AMvLuc4Gon/dXW1pxiiEf3uMY+7PnEOg UGNeeCo2Vj8zVtG2PYU0veq/TD3Xqam2k6061xu59agJrUbnAZkLnbDyH1cRiNZ6 9eVXQyENjRym3QHYFhbnKObVrZANg==
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=Z+IGzflgxcEqhpVAcj oX+lbuiO/CmQStIzyn5v7inYE=; b=Xi1bJ/H2IP70XwUeXtxy6cxaohnPRXw9YL uVq8EotFNb3wYG+VkAJgDFx4pEOmxo4CondcCsW2g5Au65KTkqg7e6+Opm585TFa LMip5awD5B0EXFRqeIPNque/CCUoev4iadrmp4iTIWg0o6CPLlqOC1yQcbELXoZc B7IP5i/wB/K9vzNGseNoZvdFGF4XqRBkne4/jXYw5NTFEpYmHOavpEUepc2tlwbu YRE5E9PmM6J4/YpZdsbxKurEYJtlpWpjkf2j1IAflltyCO+xuES2Wwv1+jorc+vw se2IRhgLK4VUH7v9hBliBj5KTf3Fx+5bGXXiHXZRh0DrfaXbnA0Q==
X-ME-Sender: <xms:OVTAWQyXBliucfjv8zfVCd-TXMyBkGsFwIQDRf10t6I_Q1PmafQ4NQ>
X-Sasl-enc: 4G9tEgTxIpydHLUkcty0/yxKl9bYWFInw144ZjeS01be 1505776696
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 9D61A7FA73; Mon, 18 Sep 2017 19:18:16 -0400 (EDT)
To: Sam Whited <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Mon, 18 Sep 2017 17:18:15 -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="AiXSEBLXCusRgGiQv2mLDNWbIX6fXWEdH"
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 23:18:20 -0000

On 9/18/17 9:10 AM, Sam Whited wrote:
> On Mon, Sep 18, 2017, at 08:21, Peter Saint-Andre wrote:
>> Until we can get to the bottom of this, I'm going to ask the RFC Editor
>> to "pause the presses" for a few days. I'll try to find time later today
>> to propose a sentence or two that we can add to the introduction or
>> security considerations or both.
> Thanks. Let me try again to clarify why the current state of the RFCs
> makes me so nervous, and why I think the solution isn't as simple as
> adding more copy:
> We cannot address every security concern in every RFC. This brute force
> method (adding a new paragraph to the security considerations section)
> doesn't scale, and we'll never find all the specific issues. Instead, we
> have to write standards in such a way that it actively difficult to make
> a mistake that will lead to a security flaw (not that we shouldn't
> document any potential gotchas that we can't get rid of, but we should
> also make them hard to do in the first place). One way we do this is
> with consistency. Right now, the nickname profile is the *only* profile
> that is non-idempotent, this is inconsistent.

As previously noted, the only ways I can see to create this consistency
would be to (1) change the Nickname profile to use NFC instead of NFKC,
thereby introducing even more serious problems or (2) perform major
surgery on the order of operations across all PRECIS string classes.
Neither of those alternatives is very appealing, and I would argue that
they are less appealing than proceeding with what we have right now and
in fact did have in 2015 (right now we're just making some minor fixes
and corrections to the three RFCs we published then).

> The reason this matters is that most developers won't read the RFC
> carefully (or possibly, at all). There is nothing we can do about this,
> and when developers don't read the RFC we should not blame them for the
> flaws that result. Reading an RFC is a huge amount of work, 

Not as much as writing it. ;-)

> so naturally
> most people won't. Instead we need to write specs in such a way that
> they won't break it if they just look at the examples, or just skim the
> sections that sound like they're related to what the dev is trying to
> do. 

The usual response to such an objection is: be a more responsible
developer. I know for a fact you're a responsible developer, but this
subject matter is, by its nature, difficult, and someone should not
expect to skim the examples and write a proper implementation.

> When I implemented PRECIS I did read the core RFC, built tables, added
> rules, built an API for composing those rules into profiles, and then
> went to create the profiles. I did *not* read the profile RFCs (until
> later when reviewing them for this process, but that's not something
> most devs will do). Instead, I skipped down to the section that listed
> the rules for enforcement, saw case mapping, width mapping, etc. and
> threw those the existing transformers I'd written together in the order
> specified and called it a day. If I had not been on this mailing list I
> would never have known that the nickname profile was non-idempotent.
> This is how most developers will probably do things. Adding more text to
> address security concerns won't help, since they never saw what was
> there already. If they didn't get the message from X pages of text,
> they're even less likely to get it from X+n pages.
> Even if I did notice that the nickname profile is non-idempotent, there
> are pressures against a correct implementation: multiple passes over the
> data makes an already expensive operation even more expensive (2–3 times
> more in the naive case) and it's just more work to do the right thing
> (whereas it's easy to pass that work onto the application developers
> using your implementation and assume they'll take care of it and iterate
> properly).

It's always more work to do the right thing. When we published the
updated XMPP RFCs in 2010, Alexey Melnikov noticed that we had not
updated the internationalization considerations and extracted a promise
from me that I would do the right thing. Here we are 7 years later and
we're still trying to get PRECIS right. This is more painful for me than
it is for you.

> All this means that, by default, the RFCs make it easy to leave the
> nickname profile non-idempotent (either by mistake, or intentionally due
> to the pressures against fixing it). 

Unfortunately we can't solve for developers not reading the specs.

> The question then becomes: "is that
> a problem?" In the case of the non-idempotency of the nickname profile,
> I think the answer is "yes".

But the solutions are even less appealing and the second alternative
(starting work PRECIS 2.0) is simply not going to fly right now because
it would require rechartering the working group and I sense zero
organizational support for that initiative.

> For a somewhat concrete example, imagine a multi-user chat room. If a
> user connects and sets their nickname, a single iteration of the
> nickname profile is run on it, and it *should* match another user in the
> room but doesn't because of this issue, that user can use the nickname
> and is allowed into the room. This may be fine, we expect this to happen
> anyways on occasion because we're using the freeform class. Now,
> however, the user sends a query to the server that is handled by a third
> party system; maybe it's a file upload that is delegated to another
> server which stores the file at /files/<nickname>/myfile. This second
> application applies the nickname profile again, however, this now makes
> it identical to the original users nickname (because the fileserver got
> a nickname that the chat server already enforced) and their files get
> stored in the same place, meaning the new user whos nickname is slightly
> different can overwrite the first users files and use that to send
> malicious files to the original chat participants friends even though as
> far as the chat system is concerned they are separate users. This is a
> silly contrived example, and maybe the administrators shouldn't have
> been using the nickname profile for their filenames in the first place
> in this case, but any time there are two systems that might both enforce
> the nickname profile you end up with a possible inconsistency like this,
> and I'm sure there will be one where it feels perfectly reasonable to
> use the nickname profile, but where the actual vulnerability comes from
> the fact that you don't expect the nickname to end up being different
> between the two systems. Note that in this example that it only matters
> that the chat server used a broken implementation that did not iterate
> multiple times, the file server could be using a perfectly correct
> implementation and the issue would still exist.

The file server is making authorization decisions based on a slippery
construct that the service operators likely don't understand even as
well as the developers (e.g., do they understand right-to-left scripts
or the complexities of various symbol code points, or have the tools to
administer such things?). I'd call that irresponsible development.
Better and safer to use the IdentifierClass or ASCII.

If your argument is that RFC 7700 should not have been published, then I
really think we're at an impasse because you're arguing against a
standards action that had IETF consensus in 2015. Even if you were to
launch an appeal against publication of 7700bis at this time, you'd have
to argue against the diff from 7700, not the basic concept or approach.
Your only avenue is to publish an Internet-Draft requesting that RFC
7700 is harmful to the Internet and should be made Obsolete.

Look, Sam, I agree that perhaps someday we can do better, but the level
of effort to get there is significant and this working group does't have
the energy to do that.