Hi Nikos, I haven't forgotten about your message and will reply at greater length this week.
Peter On 3/31/17 2:29 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2017-03-30 at 19:45 -0600, Peter Saint-Andre wrote: > >>> I'm checking both rfc7564 and rfc7613, and I cannot find the >>> rationale >>> of the restrictions being done. In particular: >>> 1. why rfc7613 restricts all spaces for passwords to U+0020? >> >> > [...] >>> 2. what is the purpose of "Contextual Rule Required" in section >>> 4.3.2 >>> of rfc7564? >> >> It's complicated, but in essence PRECIS is consistent with IDNA2008 >> here >> (see RFC 5891, RFC 5892, and RFC 5894). In particular, the code >> points >> ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are >> necessary to produce certain combinatiosn of characters in certain >> scripts (e.g., Arabic, Persian, and Indic scripts) but if used in >> other >> contexts can have consequences that violate the principle of least >> user astonishment. > > I think that such issues should warrant extensive discussions in an RFC > like 7613. It is not apparent for me for example why that principle > should apply for passwords (which are not visible). I guess there are > arguments for that, but should be presented in order to understand and > be able to convince people that RFC7613 is the way to go. > >> 3. why freeform class doesn't allow "Old Hangul Jamo characters"? >> As explained in §2.9 of RFC 5892: >> >> Elimination of conjoining Hangul Jamo from the set of PVALID >> characters results in restricting the set of Korean PVALID >> characters >> just to preformed, modern Hangul syllable characters. >> Here again PRECIS is consistent with IDNA2008. > > As I am mostly restricted in the context of passwords, my question is > mostly on why is this done for the passwords. E.g., Is it because the > Hangual Jamo set is a deprecated set which may not be in use years from > now or another reason? > >>> 4. why freeform class doesn't allow ignorable charaters? >> >> These are things like soft hyphen, certain joiners, specialized code >> points for use within Unicode itself (e.g., language tags and >> variation >> selectors), and so on. They were disallowed in RFC 4013 and are >> disallowed in IDNA2008, too. >> >> By saying "PRECIS is consistent with IDNA2008" I'm not appealing to >> authority or saying that a consistency is necessarily a good thing. >> Instead, defining as few string handling methods as possible helps >> users >> because strings aren't handled differently in different protocols and >> contexts (see §5.1 of RFC 7564). This has security implications, too, >> because the more such methods exist the easier it will be for >> attackers to trick users. > > In the context of 'passwords', I see very little applicability of such > attacks, though I may be wrong. The main concern I see for passwords > used for storage is compatibility, e.g., even with legacy software > which did not follow these rules, and simplicity, so that software can > follow the rules under reasonable for the task effort (I find the > effort RFC7613 requires for processing UTF-8 passwords unproportionaly > complex to the effort needed for US-ASCII passwords). > >>> The context of that, is that I am trying to understand what would >>> be >>> the drawbacks from recommending a fixed normalization form (e.g., >>> NFC), >>> for passwords, in contrast to recommending rfc7613. >> >> Nikos, instead of asking us why the foregoing restrictions were made, >> ask yourself why you would want to ignore them and whether you >> understand internationalization well enough to independently craft >> appropriate rules and guidelines for the RFC you're updating. Because >> you actively work on security technologies, think of it this way: >> would >> you want someone who doesn't understand all the issues to "just use >> TLS" >> without specifying appropriate cipher suites (ignoring RFC 7525) or >> certificate checking procedures (ignoring RFC 5280 and RFC 6125)? The >> issues involved with internationalization are just as complex (albeit >> in different ways) and the whole reason we developed IDNA2008 and >> PRECIS is so that well-meaning folks like you don't shoot yourselves >> in the foot. > > I cannot disagree with that, however, providing rationale for the > decisions is important, especially in documents which are developed in > disconnect with many existing protocols/practices. The current state in > PKCS#12, PKCS#8 encrypted files, is pass there whatever you have as > long as it is UTF-8. Convincing developers to deploy thousands lines of > code for pre-processing such passwords, would require to underline the > problems of the previous practice. RFC7613 unfortunately ignores that > part completely, and I have no arguments when trying to convince people > that this should be preferred. > >> I strongly encourage you to use the PRECIS profile for passwords in >> RFC7613, and we'd be happy to help you do so in the safest ways >> possible. > > I'm trying to make a list of items which make apparent why RFC7613 is > needed. What I have now is: > > "UTF-8 however, does not imply that strings conforming to it, are > unambiguously unique, since there are can be various forms of the same > string which may look identical to an observer, although being > represented by a different byte string. Some issues are the following." > > [The NFC argument is the easier to explain] > * Various normalization forms, which result to different data for the > same input. > > [why spaces need to be merged to 0x20 is harder to sell] > * The unicode standard includes a number of space characters which > cannot be distinguished from each other, or have no width resulting to > different results when switching to a different input method > > [Hangual Jamo even harder] > * There are deprecated alphabet sets, which are no longer in use(?) > and may not be available as input methods in the future. > > [contextual rule] > * Certain combinations of code points between certain scripts produce > unexpected visible results. (the question here is why would one care > for visible results on passwords which are not printed) > > regards, > Nikos > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
