SASLprep200x

Vint Cerf vint at google.com
Fri Jan 5 00:39:37 CET 2007


I would argue strongly that we should NOT allow DNS to be conflated with
strings used as passwords - these should be absolutely distinct in the sense
that the DNS rules really need to be constrained for reasons far beyond
anything one might associate with password preferences.

Vint
 


Vinton G Cerf
Chief Internet Evangelist
Google
Regus Suite 384
13800 Coppermine Road
Herndon, VA 20171
 
+1 703 234-1823
+1 703-234-5822 (f)
 
vint at google.com
www.google.com
 

-----Original Message-----
From: idna-update-bounces at alvestrand.no
[mailto:idna-update-bounces at alvestrand.no] On Behalf Of Paul Hoffman
Sent: Thursday, January 04, 2007 11:22 AM
To: idna-update at alvestrand.no
Subject: SASLprep200x

At 10:22 AM +0100 1/3/07, Simon Josefsson wrote:
>There is one assumption that is often made in IDNA discussion, and that 
>is that IDNA strings are assumed to contain "natural language", or put 
>differently, that strings that you would never find in a newspaper or 
>spoken by a human, are not worth consideration.

That is an unfair characterization. Such strings are not considered as high
priority, but they are definitely worth consideration, given that we cannot
predict which strings might be in a newspaper and/or spoken in the future.

>That assumption doesn't hold for passwords.  The more entropy you can 
>put into a password, the better.  Picking a password that, for some 
>reason, never would have been part of a dictionary or printed in a 
>newspaper is a _good_ idea.

Quite true.

>This is one case where I think the design goals of StringPrep and 
>SASLPrep are different.  If this issue is not taken into consideration 
>in the StringPrep200x design, I think SASLPrep will ultimately have to 
>be forked and have a separate design.

Fully agree. The current SASLPrep works OK because of our liberalness in the
original Stringprep; a future SASLPrep based on a more conservative
Stringprep would inherently be more limited.

>That would be unfortunate,
>since much of the work is duplicated.

Fully disagree. If the SASL community wants to change SASLprep to use more
characters, they can revise their current standard; they don't need to use
StringPrep200x. Under no circumstances should the DNS work be limited by the
password work.

>It seems better if StringPrep
>allowed this, and when desired, the upper-level IDNA architecture 
>disallow such strings.  Then SASLPrep200x may use StringPrep200x.

...at the expense of greater confusion that, in my opinion, is not worth it.
The SASL folks are quite able to do their own extension of their base spec.
_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update



More information about the Idna-update mailing list