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

From: [email-masked]
Date: Sun, 16 Jul 2017 16:20:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF.

        Title           : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
        Authors         : Peter Saint-Andre
                          Marc Blanchet
	Filename        : draft-ietf-precis-7564bis-09.txt
	Pages           : 44
	Date            : 2017-07-16

Abstract:
   Application protocols using Unicode code points in protocol strings
   need to properly handle such strings in order to enforce
   internationalization rules for strings placed in various protocol
   slots (such as addresses and identifiers) and to perform valid
   comparison operations (e.g., for purposes of authentication or
   authorization).  This document defines a framework enabling
   application protocols to perform the preparation, enforcement, and
   comparison of internationalized strings ("PRECIS") in a way that
   depends on the properties of Unicode code points and thus is more
   agile with respect to versions of Unicode.  As a result, this
   framework provides a more sustainable approach to the handling of
   internationalized strings than the previous framework, known as
   Stringprep (RFC 3454).  This document obsoletes RFC 7564.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-precis-7564bis-09
https://datatracker.ietf.org/doc/html/draft-ietf-precis-7564bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Jul 2017 19:40:42 -0600

> 	Filename        : draft-ietf-precis-7564bis-09.txt

Our area director pointed out to me offlist that the definition of
"reasonable" is vague in the following text:

   Because of the order of operations specified here, applying the rules
   for any given PRECIS profile is not necessarily an idempotent
   procedure (e.g., under certain circumstances, such as when Unicode
   normalization form KC is used, performing Unicode normalization after
   case mapping can still yield uppercase characters for certain code
   points).  Therefore, an implementation SHOULD apply the rules
   repeatedly until the output string is stable; if the output string
   does not stabilize within a reasonable number of iterations, the
   implementation SHOULD terminate application of the rules and reject
   the input string as invalid.

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.

Peter

---

From: Sam Whited <[email-masked]>
Date: Wed, 19 Jul 2017 23:44:56 -0500

> sense is that we're talking about at most 4 or 5, and usually 2 or 3.

For now we've avoided dealing with this in the Go implementation by
documenting that the nickname profile (which I think is the only
profile to suffer from this right now?) is not idempotent and passing
the requirement to iterate on to the users (application developers
using the library).
However, I suspect many of them will not read the warning in the docs
and will apply the profile once, which may be a security concern.
Because we can't be absolutely sure (or can we?) that a string will
stabilize after any given number of iterations or that the number of
required iterations won't change in the future as new characters are
added, and because this introduces a tradeoff that must be made
between performance and correctness, I think that idempotency should
be a requirement for all standardized PRECIS profiles.
However, I understand that this is a large change that may not be
possible to make this late in the game.

I don't think we'll special case the nickname profile to to make it
run multiple times in our implementation, but I'm also not sure what
we'll end up doing. It may be that we roll our own profile for
nicknames and break compatibility with other libraries (although this
is obviously not desired), or we may not support the nickname profile
at all and leave it up to application developers to implement if they
need it, or we may simply leave a big scary warning in the
documentation. None of the options sound appealing.

—Sam

---

From: William Fisher <[email-masked]>
Date: Wed, 19 Jul 2017 22:30:56 -0700

> sense is that we're talking about at most 4 or 5, and usually 2 or 3.

I interpreted the word "iteration" to mean "reapplication" of the
rules; not counting the first application. The Nickname test cases
become stable after 2 iterations of the rules.

  output1 = precis_encode(input)
  output2 = precis_encode(output1)      # iteration 1
  output3 = precis_encode(output2)      # iteration 2 confirms that
output3 == output2

I can't come up with a Nickname test case that requires more than 2
iterations to become stable, but that doesn't mean they don't exist.
It's possible that a new PRECIS profile could be defined that has
stability issues. IMO, if a PRECIS profile isn't stable after 3
iterations, it's broken.

The last sentence might read like this:

  Therefore, an implementation SHOULD reapply the rules
   repeatedly until the output string is stable; if the output string
   does not stabilize after three iterations, the
   implementation SHOULD reject
   the input string as invalid.

In the worst case, this means that you are calling precis_encode()
four times for an input string.

-Bill

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 Jul 2017 21:08:13 -0600

> iterations to become stable, but that doesn't mean they don't exist.

As far as I can determine based on reviewing various code points, that's
right. This _should_ be a function of the code points involved (i.e.,
how many steps a code point is from something more stable), not the profile.

> stability issues. IMO, if a PRECIS profile isn't stable after 3

Agreed.

> four times for an input string.

That seems reasonable.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Jul 2017 17:40:46 -0600

>> four times for an input string.

All three of the PRECIS I-Ds have identical text on this point. Based on
Bill's message, I propose that we change the sentence as follows:

OLD

   an implementation SHOULD apply the rules

NEW

   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, the implementation SHOULD terminate application of the rules
   and reject the input string as invalid.

For the sake of traceability, I'll submit revised versions of all three
I-Ds this evening.

Peter