Re: Security

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

Kurt Zeilenga wrote:

  [TLS]
>> That places restrictions on specifications, not implementations,
>> which is somewhat weird, but CRAM-MD5 could do the same.  That
>> is what I propose to do.
 
> I personally think such a change would be good.   I feel that TLS
> recommendations to protect CRAM-MD5 ought to be the same as those
> we made for the TLS protection of PLAIN.

Could work.  What about existing protocols, has this to be limited
to future specifications ?  Normally we say "SHOULD" when we mean
"old stuff has a good excuse, its old".  IIRC there are a two old
protocols with a mandatory CRAM-MD5, one of them (on demand relay)
won't be updated anytime soon, if ever.

  [i18n]
>> SHOULD has worked fine for PLAIN, so I disagree.
> 
> It works fine because of PLAIN's design.  The party, the server, is  
> preparing both the presented and stored strings.   In CRAM-MD5, two  
> parties need to agree on the preparation on what preparation to use  
> for things to work properly.

I don't get this point.  A new user creating an account picks a
free userid, and a password.  The details can vary, one way is
online in a Web form.  If the server can note these credentials
for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
in any required format(s), even the somewhat odd "APR1" format.

In what way is the design of PLAIN different ?  Like CRAM-MD5 it
sends the userid as plain text.  

 Frank