Deneb Meketa wrote:
> Many thanks to Nelson for the excellent clarification.

BTW, I should have mentioned that the preference named:
    [] Use secure authentication
should be more accurately labelled:
    [] Use secure authentication IF AVAILABLE

> I would personally love to see those details posted somewhere.  If no 
> one suggests otherwise, I may add something to "Tips & Tricks" and to 
> the email section of the Mozilla security center.

You mean somewhere besides ?

> But that's a tangent.  I'd like to make a radical proposal for revising 
> the UI and adding an automatic mode.  This is totally blue-sky, so let 
> me know if I'm talking crazy talk.
> I propose to have the UI look like this:
>    Connection Security
>      Most users should choose "Automatic", which allows Thunderbird
>      to choose the most secure mode that your server supports.
>      (o) Automatic (currently this is SSL)  [[Re-negotiate now]]
>      ( ) SSL (fully secured)
>      ( ) StartTLS (fully secured, alternate mode)
>      ( ) CRAM-MD5 (encrypted password, unsecured mail exchange)
>      ( ) No security
> The default would be automatic mode. 


Add comments and votes there.

If you're going to have an automatic mode, then I think you need check-boxes
(not radio buttons) to allow the user to specify which methods are
permissible to be tried.

Or perhaps it suffices to have a check box that says:
    [] NEVER use plain text unencrypted passwords.

My beef with this whole mess is that it seems to assume that it can always
fall back on plain text passwords, even if I specifically want to avoid that.

It used to be worse.  It used to try plain text passwords even if the
server plainly told it not to do so.  But that was eventually fixed.
So, now it obeys the remote server's wishes, but not the local user's.  :(

See also bug which was
JUST fixed (fix has not yet appeared in any official builds, but is in some
nightly test builds).

Automatic mode must start by trying the most secure flavor, and work its
way down.  It must NOT start by sending the password in the clear.
And it should not send the password in the clear without explicit user

> Note that I have deleted the "TLS, if available" mode.  I agree with 
> Nelson that this is probably not useful.  I think most users would want 
> to know if their security mode changed, and you really wouldn't expect 
> this to change once it was established.  

A few years ago, there was a very vociferous group loudly promoting
something they called "opportunistic encryption", which was basically
a plan to encrypt whenever you can (without asking the user) but falling
back to no encryption (also without telling the user) whenever you cannot
do encryption.  I think the "TLS if available" feature was added to
satisfy them.  But with that scheme, the user simply has no control over
whether encryption is used, and no way of knowing if it was used.  It is
trivial for an attacker to force the client to not use encryption, when
that feature is selected, which means it's worthless for providing real

If we pull that back out, I wonder if the "opportunistic encryption"
crowd will raise their voices again, and if this time maybe Mozilla will
have the back-bone to just say no, instead of caving in.

> Finally, note that this proposal only offers CRAM-MD5 when neither SSL 
> nor StartTLS is in use.  This eliminates the confusing separate checkbox 
> that started this whole thread.

I see no reason to make CRAM-MD5 mutually exclusive with SSL/TLS.

> How's all this sound?

Sounds great, but won't go anywhere until someone is willing to work on
the code to implement it.  Right now there's only one person doing ALL
the mail/news back end work for all mozilla products.  Seems everyone
loves to work on UI, but no-one wants to work on the hard stuff, the
back end.  So, people can "wish" and "vote" for all the great ideas they
want, but until someone IMPLEMENTS them, they're just beggars' horses.

Nelson B
dev-security mailing list

Reply via email to