On 9/17/17 2:51 PM, Sam Whited wrote: > On Sun, Sep 17, 2017, at 15:41, Peter Saint-Andre wrote: >> 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. > > 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. > >> 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. > > 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, 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
