31799 - UI: turning off ciphers is confusing; cipher may still be used

Status: VERIFIED INVALID

(Core :: Security: PSM, defect, P2)

Description

[ko]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #62313
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=62313
Imported into Bugzilla on 03/14/00 10:37)

User A uses the en-us.zip as policy.jar file. In the Configure Ciphers dialog in 
the Messenger frame of the Security Advisor, he checks only DES EDE3 168-bit key 
and RC2 128 bit key for encryption.

User B uses the en-export.zip as policy.jar file (default).

1. User A sends User B a signed message.
2. User B reads User A's signed message, and send User A back an encrypted 
message.

The message is encrypted with DES 56-bit key, not the way User A specified. In 
fact User A sees the message is encrypted, and will falsely believe that the 
message is encrypted better than it actually is.

User B should not be able to send User A any encrypted message in this case. A 
warning message should come up when User B tries to do it.

------- Additional Comments From repka  05/02/97 13:01 ------- 

According to what you described, the message should have ended up
encrypted with RC2 and a 40-bit key, not with DES.  But I'll check
into that.  The behavior of encrypting the message with RC2/40,
however, is correct.  Accepting this bug for b5 in the chance that
we can find a better way to express this behavior in the UI.

------- Additional Comments From repka  05/06/97 10:51 ------- 

When I followed the steps, the message ended up encrypted with
RC2 and a 40-bit key, which is the intended behavior.  I'm not
sure why Japheth got DES; that behavior would be wrong -- when
the sender has no obvious algorithm and keysize to choose from,
it should always "fallback" to RC2/40.

------- Additional Comments From repka  05/06/97 10:54 ------- 

*** Bug 62318 has been marked as a duplicate of this bug. ***

------- Additional Comments From repka  05/06/97 11:13 ------- 

Changing the summary line and the priority/severity; the algorithm
choosing code is behaving as it should, but the UI is broken and
confusing.

------- Additional Comments From repka  05/07/97 12:01 ------- 

Japheth and Lisa -- would it be appropriate to Release Note this behavior?
The only way I can see to "fix" this bug is to explain to the user how
it really works, because the behavior is as expected.  I initially thought
this could be best accomplished by adding some text to the S/MIME
Cipher Selection dialog window, but changing the UI now by adding a new
string is, as I think you know, a monumental task.  So, I think our
only ptions are: try to add a couple of sentences to the dialog window
(convincing mtoy and mindy that this is really necessary), or add
something to the Release Notes, or do nothing at all for Dogbert.
I'd appreciate your input in this -- and, if you want the first option,
I'll need your help in convincing mtoy and mindy that this change is
important.  Thanks.

------- Additional Comments From lchiang  05/07/97 13:41 ------- 

This explanation could be added to the on-line help rather than release notes.  
It appears that the Security Advisor dialog has a Help push button.  What do you 
think, Japheth?  I don't know what the deadlines for the Help contents are.


------- Additional Comments From ko  05/07/97 15:55 ------- 

I prefer UI change, if it is possible. Otherwise I would propose no change, and 
make sure we document the behavior in NetHelp. (We'll then make the change in 
4.01/4.1 if there's one, or 5.0.) I don't think Release Notes is the place to 
document the behavior either.

------- Additional Comments From repka  05/07/97 17:58 ------- 

Okay, I tried to get the UI change in, but it was rejected by
mtoy and mindy.  If you still feel strongly about it, I suggest
you try your own hand at convincing them.  They may still agree,
but I won't try any more.  (FWIW, the change itself is very easy;
the hardest part is choosing the right words to say it succinctly
but clearly.)

So, my plan is to LATER this bug, and I will try to put the words
in the UI in whatever is the next appropriate release.  In the meantime,
how do we go about getting something into the on-line help?  I guess
I shouldn't be so ignorant, but I actually have no idea...  

------- Additional Comments From jsw  05/07/97 18:11 ------- 

Lisa, if you have the words you want to use, you should probably add
them to the bug so that they don't get lost.

You can talk to Mike Melton([e-mail]) about the help content.

------- Additional Comments From repka  05/07/97 18:40 ------- 

I had stashed away the words so I'd have them later, but no problem
putting them here for safekeeping, too.  Now that I have a little time,
I will continue to rewrite these words because I don't like them all
that much.  In any case, they would show up on the "Select S/MIME Ciphers"
HTML dialog, after the checkbox-list of ciphers.
    "The enabled ciphers are included in your signed messages as an
     indication of your preference for the method of encryption used
     for messages which are sent to you.  Disabling a particular
     cipher does not guarantee a sender will not use it anyway."

I also sent mail to Mike Melton.  Once I know this is going to get
handled in online-help, I will close this bug as LATER.

------- Additional Comments From repka  05/09/97 11:47 ------- 

Mike Melton said he would try to get this into online-help, so I'm
now marking this as officially LATER.  We will try to make the cipher
preferences dialog more explanatory in the next release.

------- Additional Comments From repka  07/11/97 10:08 ------- 

Reopening this as a potential for being fixed in 4.02, if can get
approval for the UI change.

------- Additional Comments From repka  07/15/97 10:25 ------- 

Adding a "UI:" to the front of the summary line, as per Mindy's request.


------- Additional Comments From repka  07/15/97 16:36 ------- 

I could tell that this fix was not going to be accepted for 4.02,
so I'm just moving it to 5.0.

------- Additional Comments From mindy  07/15/97 23:02 ------- 

this ui change was rejected for all 4.x releases.  This should be fixed in 5.0. 
 Thank you.

------- Additional Comments From repka  08/08/97 18:52 ------- 

Passing along to Mark Welch, new owner of S/MIME.  It may actually make
sense to fix this in 4.03, not in 5.0 -- that's up to Mark and others.
(I don't know if 4.03 is going to be localized; if not, then fixing it
in 4.03 should be no problem, and it would then get moved over into
5.0 along with the rest of the 4.03 changes.)

------- Additional Comments From repka  05/16/98 14:44 ------- 

Fixing cc list and assigning this back to me.  I can fix this bug
whenever someone will let me change some words in the UI.  That's
all this bug needs.  (Well, that and some inspiration to determine
the right words -- there isn't a lot of space to convey the somewhat
complex information...)

------- Additional Comments From paulmac  03/30/1999 11:40 ------- 

Moving all Security TFV 5.0 bugs to TFV 5.0 SF1in in preparation for moving them 
to Bugzilla (per leger)

------- Additional Comments From kristif  03/30/1999 13:45 ------- 

Changing kristif to rudman in cc: list in case release notes or other docs need 
attention.

------- Additional Comments From marek  Mar-01-2000 17:01 ------- 

mass-changing all old Communicator and Communicator Pro bugs filed for 
Comm. and Nav. versions older than 4.5 to WONTFIX.
If you feel this was done in error, please reopen and reassign hong for 
consideration in 4.7x (assuming that you have a reproducible test case -- if you 
don't please don't reopen until you have one)

Comment 1

[Lisa Repka]

Giving bug new life in mozilla.  Cleaning up some fields -- more changes
in next revision when bug is offically reopened.

Comment 2

[Lisa Repka]

This is actually a two-fold PSM problem -- the cipher-setting isn't
even currently provided by PSM.  If it were, the old wording would *not*
be the stuff to use.  (And this is related to yet another problem,
which is we don't give the user any control over what ciphers they
*send*.  The cipher-setting in question here is about what they *receive*.
But the sending problem is a separate one, and is probably covered in
another bug which I am trying to find.  Will add another comment if/when
I do.)  FYI, somewhere in the bug text above is an example of improved
wording.  It is still yucky, though.  There must be a decent way of
conveying to the user what the cipher-setting (which, btw, causes a
manipulation of the user's cipher-preferences in the SMIMECapabilities
sent with every one of their signed messages).  Good luck.

Comment 3

[John Unruh]

Marking invalid. Mozilla with PSM doesn't even have a UI to turn off individual 
ciphers.

Comment 4

[John Unruh]

Verified. Please open new bugs if there are still cipher issues with Mozilla 
with PSM.