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

[Peter Saint-Andre <[e-mail]>]

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

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

Peter