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

From: Sam Whited <[email-masked]>
Date: Fri, 08 Sep 2017 09:13:35 -0500

On Wed, Jul 19, 2017, at 23:44, Sam Whited wrote:
> On Wed, Jul 19, 2017 at 8:40 PM, Peter Saint-Andre <[email-masked]>
> wrote:
> > What do implementers think is a "reasonable number of iterations"? My
> > sense is that we're talking about at most 4 or 5, and usually 2 or 3.

Apologies for the long delay, I know this thread is rather old now, but
I was just reminded of this blog post [1] from Spotify that shows that
the non-idempotency of the nickname profile is already a security issue
in the wild and that documenting the fact that it may have security
implications only goes so far.

—Sam

[1]: https://labs.spotify.com/2013/06/18/creative-usernames/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Sep 2017 21:38:56 -0600

> [1]: https://labs.spotify.com/2013/06/18/creative-usernames/

The Spotify folks faced numerous issues, including the fact that they
implemented against an unfinished spec. I'd say that if they now used
the PRECIS specs (especially the new ones about to be published) as
their guideline, things would have gone much better.

Peter

---

From: Sam Whited <[email-masked]>
Date: Thu, 14 Sep 2017 09:06:19 -0500

> their guideline, things would have gone much better.

I agree as far as the username profiles go (which is actually what they
were doing), the major issues with those have been fixed as far as I can
tell from my implementation / limited usage. Let's do the same for the
nickname profile before publishing another since there is a history of
this being a problem.
—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Sep 2017 20:04:44 -0600

> nickname profile before publishing another since there is a history of

What needs fixing? We added explanatory text about idempotence, and
there will also be an example of such in the RFC version.

Please note that these documents are now in AUTH48 (very final edits
before publication). So speak now or forever hold your peace!

Peter

---

From: Sam Whited <[email-masked]>
Date: Sun, 17 Sep 2017 14:13:36 -0500

> there will also be an example of such in the RFC version.

That is not enough. Someone writing a PRECIS implementation *might* see
that. Someone actually using the PRECIS implementation (eg. the author
of an XMPP Client, Spotify, etc.) will most likely not see that. If
they're lucky, the text will have been copied over into the
implementations documentation. That's a lot of "if's".

> before publication). So speak now or forever hold your peace!

I brought this up earlier as well. I wanted to bring it up again because
the Nickname profile is getting so close to being published again with
something that I think is possibly a security concern and that needs to
be fixed since we won't have this opportunity again.

—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 14:41:35 -0600

> implementations documentation. That's a lot of "if's".

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.

> be fixed since we won't have this opportunity again.

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.

Peter

---

From: Sam Whited <[email-masked]>
Date: Sun, 17 Sep 2017 15:51:46 -0500

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

> 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

---

From: William Fisher <[email-masked]>
Date: Sun, 17 Sep 2017 13:54:28 -0700

On Sun, Sep 17, 2017 at 12:13 PM, Sam Whited <[email-masked]> wrote
> implementations documentation. That's a lot of "if's".

In the python implementation, the Nickname profile reapplies itself a
second time to handle the non-idempotent cases. In addition, all
profiles defensively verify that they are returning an idempotent
result. If a result is determined to not be stable/idempotent, the
code returns a "DISALLOWED/not_idempotent" error for the input.

If someone writes their own Profile, the Profile subclass is
responsible for iterating to avoid the "not_idempotent" error.

> be fixed since we won't have this opportunity again.

IMHO, requiring a non-idempotent PRECIS profile to iterate to resolve
idempotency issues mitigates the security issue. I do think this is
the PRECIS implementation's responsibility.

I have a vague suspicion (untested) that the double Nickname composition:

     result = nfkc(tolower(additional(nfkc(tolower(additional(input))))))

may be equivalent to the composition that you might get if you fixed
the Nickname profile by re-ordering the steps.

    result = tolower(additional(nfkc(input)))

-Bill

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 14:55:22 -0600

> evidence that this is a real problem than I had before.

In that case, we'll need to invoke the WG chair and/or AD.

Peter

---

From: Sam Whited <[email-masked]>
Date: Sun, 17 Sep 2017 15:57:39 -0500

> In that case, we'll need to invoke the WG chair and/or AD.

Thank you, I would appreciate it, but am also aware that my opinion
really means nothing here since I am not related to the WG. Do as you
see fit; I just wanted to make sure this issue was brought up again
before these documents were approved, since this may be our only chance
to fix this for a while.

—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 14:59:16 -0600

> In that case, we'll need to invoke the WG chair and/or AD.

I have forwarded this note to the chair and AD with a suitably scary
subject line. If we don't hear back from them before 8 AM Pacific time
tomorrow, I will send a similar note to the RFC Editor team to stop the
presses.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 15:00:39 -0600

On 9/17/17 2:57 PM, Sam Whited wrote:
> really means nothing here since I am not related to the WG.

Sam, you are very much part of the WG. The IETF doesn't require
membership, just participation, and you're participating.

> Do as you

That is very true.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 18:02:34 -0600

> 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
       CAPITAL LETTER V).

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

Peter

---

From: Sam Whited <[email-masked]>
Date: Sun, 17 Sep 2017 19:37:23 -0500

> various PRECIS specs. If we need to add more warning text to 7700bis,

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

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

> 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

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

—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 17 Sep 2017 20:56:06 -0600

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

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

> 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

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.

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

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

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.

Peter

---

From: Sam Whited <[email-masked]>
Date: Sun, 17 Sep 2017 22:32:26 -0500

> Should we add a sentence about this to 7700bis?

I suppose it couldn't hurt, but I'm not sure that it's necessary either.
I was not attempting to suggest that the issue was that they would use
the nickname profile for authentication, but that misusing it could be
an issue in its own right.

> or forever hold your peace.

That's what I'm doing right now :)

> You'd be going against the consensus of the

I do seem to be the lone dissenter in this matter and since I no longer
have a job that allows me the time to work on open source or standards
in any serious way outside of the weekends I'm afraid I won't be able to
make a better argument than what I've tried (poorly) to present in this
email chain.

—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Sep 2017 07:21:57 -0600

> I suppose it couldn't hurt, but I'm not sure that it's necessary either.

I thought about it more overnight and I will look more closely at the
security considerations and introduction later today. I do think a
sentence or two would help.

> an issue in its own right.

The spec as written attempts, via use of NFKC, to prevent the most
egregious misuse (as quoted previously in this thread).

> That's what I'm doing right now :)

Actually you're arguing against the prior publication of RFC 7700, too,
which is why IMHO the burden of proof is a bit stronger - that was,
after all, a document that had IETF consensus.

> I do seem to be the lone dissenter in this matter 

Numbers are unimportant. RFC 7282 discusses this kind of scenario. What
matters is the issue, not the person who raises the issue or the number
of people who voice agreement.

> and since I no longer

Communication is a two-way street. I get the sense that I haven't fully
understood your concern - it's open to interpretation whether you've
poorly presented the argument or I haven't grasped its implications.

As I've tried to express, there are legitimate concerns with the
Nickname profile or with any profile of the FreeformClass, but as far as
I can see we've done everything possible (via use of NFKC etc.) at this
stage in the development of internationalization technologies at the
IETF to address those concerns (or at least the concerns we've all had
for a long time - perhaps you are raising a new concern, which we need
to figure out).

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.

Peter

---

From: Sam Whited <[email-masked]>
Date: Mon, 18 Sep 2017 10:10:45 -0500

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

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

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

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

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.

—Sam

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Sep 2017 17:18:15 -0600

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

> flaws that result. Reading an RFC is a huge amount of work, 

Not as much as writing it. ;-)

> so naturally

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.

> using your implementation and assume they'll take care of it and iterate

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.

> to the pressures against fixing it). 

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

> The question then becomes: "is that

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.

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

Peter

---

From: Sam Whited <[email-masked]>
Date: Mon, 18 Sep 2017 19:24:05 -0500

> of effort to get there is significant and this working group does't have

If there's no energy to make the change then I don't see any reason to
continue this discussion. It sounds like I'm disagreeing with something
that's fundamental to the construction of PRECIS, so if the change isn't
going to be made either way there's no point in holding publication of
the current drafts.

Thanks for discussing it and helping me understand the problem more
fully.

—Sam

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 19 Sep 2017 07:40:09 -0400

> going to be made either way there's no point in holding publication of

That is also my conclusion. You have raised good points, some were 
discussed before, but if the end resolution is to redesign precis (such 
as changing the normalization form which is a major redesign), then I 
think we shall proceed with the publication and then some people like 
you can start another round of revisions of the documents. As you may 
know, the first iteration of this work was called Stringprep (RFC3454), 
then we moved to the new IDNA framework based on Unicode rules which led 
into Precis. At the time of Stringprep, we already knew some of its 
weaknesses. Neither Stringprep or Precis is perfect. So I encourage you 
to write a proposal and submit it as internet-draft (and advertise it to 
this mailing list).

Marc.

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Sep 2017 09:39:55 -0600

> sentence or two would help.

Here is some proposed text to address part of Sam's concern.

First, in the Introduction...

OLD

   The rules specified in this document can be applied in all of the
   foregoing contexts.

   To increase the likelihood that memorable, human-friendly names will
   work in ways that make sense for typical users throughout the world,
   this document defines rules for handling nicknames in terms of the
   preparation, enforcement, and comparison of internationalized strings
   (PRECIS) framework specification [RFC8264].

NEW

   The rules specified in this document can be applied in all of the
   foregoing contexts.

   It is important to understand that a nickname is a personally
   memorable name or handle for something that has a more stable,
   underlying identity, such as a URI or a file path. To ensure secure
   operation of applications that use nicknames, authentication and
   authorization decisions MUST be made on the basis of the thing's
   identity, not its nickname.

   To increase the likelihood that memorable, human-friendly names will
   work in ways that make sense for typical users throughout the world,
   this document defines rules for handling nicknames in terms of the
   preparation, enforcement, and comparison of internationalized strings
   (PRECIS) framework specification [RFC8264].

Second, we might repeat that paragraph in a new subsection of the
Security Considerations, too.

Third, I suggest that we move the following paragraph from the end of
Section 4 to the end of Section 2.1:

   Implementation experience has shown that applying the rules for the
   Nickname profile is not an idempotent procedure for all code points.
   Therefore, an implementation SHOULD apply the rules repeatedly until
   the output string is stable; if the output string does not stabilize
   after reapplying the rules three (3) additional times after the first
   application, the implementation SHOULD terminate application of the
   rules and reject the input string as invalid.

Peter