IDNA and SASLPrep, etc. (was: Re: Requirements document (Re: New version, draft-faltstrom-idnabis-tables-02.txt, available))

[John C Klensin]

--On Monday, 18 June, 2007 12:53 +0200 Simon Josefsson
<simon at josefsson.org> wrote:

> "Vint Cerf" <vint at google.com> writes:
> 
>> I would have thought that consideration of passwords is
>> entirely irrelevant to the consideration of characters to be
>> used in domain names.
> 
> StringPrep is part of the IDNA algorithm, and StringPrep is
> used for non-IDN purposes.  See SASLPrep:
> 
> http://www.ietf.org/rfc/rfc4013.txt
> 
> If you want to revise StringPrep, I believe you should take
> into considerations the non-IDN purposes as well.
> Alternatively, explicitly declare that you don't care about
> the non-IDN users.

Simon, your point has been made, discussed, and understood.
IDNAbis _will not_ use Stringprep or undermine SASLPrep in any
other way.    The underlying problem here, if there is one, is
that we were somewhat naïve about the differences between "best
character set for passwords and passphrases" and "best
characters for IDNs" when RFC 3454, 3490, 3491, and 4013 were
created.   The problem was somewhat covered over by the fact
that 3490/3491 tried to include, in one way or another, all
Unicode characters that were not clearly problematic.   As soon
as we concluded (see RFC 4690) that IDNs needed an "only
designated characters" list that was intended to minimize
confusion and other problems (to the extent possible), its goals
and character sets diverged from the requirements of
passwords.... a realization for which your comments were
invaluable.  

To quote from a note I wrote earlier today in another context: 

> I do want to stress that the bottom line for most
> security-related issues is that there was an assumption when
> stringprep was produced that, with small variations, one
> profile would be optimal for everything.  In retrospect, that
> assumption was nuts.  The easiest example is the one Simon has
> raised repeatedly: while special, bizarre, and confusable
> characters are bad news for the DNS and email addresses, they
> may be wonderful for things like passphrases in which the user
> knows what characters he or she is typing and merely needs to
> reproduce it from one session to the next.  Consider, e.g., the
> plight of a shoulder-surfer trying to remember a mixed-script
> string in which some of the characters are visually ambiguous
> or someone trying to intercept the output of a screen reader
> that can't render arbitrary Unicode.
>...

I do believe that some of the things we have learned in looking
at IDNA -- especially the issues that you and Martin discussed
about what can be typed-- should be reflected back to SASLPrep
(and perhaps elsewhere).   But that should be done because those
changes make sense for passwords, not because they make sense
for IDNA and there is some carryover.

So I think this problem is under control.  If it is not, I
expect SAAG to dismember me in Chicago.

      john