32456 - Disable SSL RC2 ciphers

Status: VERIFIED WONTFIX

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

Description

[John G. Myers]

The RC2 ciphers should be disabled by default.  They are fairly suspect these 
days and are not needed for interoperability--anything that can do RC2 these days 
can also do RC4.

Comment 1

[Chris Newman]

The more cryptanalysis a cipher algorithm has had, the safer it can be 
considered.  Since RC2 was proprietary for much of its life, it was not subject 
to serious public review and cryptanalysis.  By the time it was released to the 
public, the inventor had moved on to a new block cipher (RC5 and later RC6).  At 
least one signficiant attack against the cipher has been documented in:
J. Kelsey, B. Schneier, and D. Wagner, Related-Key Cryptanalysis of 3-WAY, Biham-
DES, CAST, DES-X, NewDES, RC2, and TEA, ICICS '97 Proceedings, Springer-Verlag, 
November 1997, pp. 233-246.
    <http://www.counterpane.com/related-key_cryptanalysis.html>
Backround on the cipher can be found in:
L. Knudsen, V. Rijmen, R. Rivest, and M. Robshaw, On the Design and Security of 
RC2, FSE5, to appear. 
    <http://www.ii.uib.no/~larsr/papers/rc2fseproc.ps.gz>
This document indicates that at the time it was written (presumably recently), 
linear cryptanalysis of RC2 was not complete.

Note that RC4 is necessary for pre-standard SSL (v3) interoperability. 
Unfortunately, RC2/40 is necessary for pre-standard S/MIME (v2) interoperability, 
but hopefully with the S/MIME (v3) standards, this can be phased out as well.

Comment 2

[John G. Myers]

So I suggest we disable the SSL RC2 ciphers and leave the S/MIME RC2/40.

Comment 3

[John G. Myers]

Working on a patch.

Comment 4

[John G. Myers]

Attachment: Proposed fix

Comment 5

[Bob Lord]

Adding the usual suspects for comments.

Comment 6

[John G. Myers]

Should I also disable SMIME_RC2_CBC_128 ?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Until such time as someone published an actual finding that these
ciphers are shown to be weak, I see no reason to disable them in NSS.

Each product that uses NSS is, of course, free to enable or disable
what ever cipher suites it wants.  

Comment 8

[John G. Myers]

This is not disabling them in NSS, this is disabling them by default in PSM.
Users are able to reenable them by editing prefs.js.

Comment 9

[John G. Myers]

...and the finding that these ciphers are weak against related key attacks is 
mentioned previously in this bug.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I oppose disabling them by default in PSM.

Comment 11

[John G. Myers]

What are the reasons behind your opposition?

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

For the same reason Lord chose to disable TLS in this release of PSM.
Do not deliberately reduce interoperability.

Comment 13

[John G. Myers]

Interoperability with what?  Do you know of any servers which support RC2 but 
not RC4?

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

We didn't know of any servers that implemented SSL3 roll-back detection
incorrectly, and hence were incompatible with TLS/SSL3 clients, until
we implemented TLS and it started getting used.  

I think we need a stronger reason to remove functionality from PSM 
than a few people don't like it.  When there's a call in the 
ietf-TLS mailing list to deprecate it, and it's widely agreed, then...

If I had prioritize things to be discontinued, I'd put SSL2 at the 
head of the list.

Comment 15

[Robert Relyea]

So after looking at Schneier's paper, I don't think we should disable Rc2 by 
default until we have UI to turn it back on.

Related key attacks require that the attack can either predict the key or choose 
the key. and force the related keys to encrypt the same cipher text. SSL keys 
are generated using basically a prng. The RC2 attack requires choosing related 
keys of the form k=(x0, x1 ...,x63) and K'= (x0', x1, ..., x63'), that is the 
first and last bytes different. That can't easily be forced in the prng. In 
addition SSL does not encrypt the same cipher text. Even if you request the same 
page over and over, SSL adds salt to the encrypted text.

S/MIME can encrypt the same text over and over again (by sending the same 
message), but to attack it you would have to convince the sender to generate the 
key by some trivial algorithm.

The related key attack is serious enough I'd never add RC2 as a new cipher, but 
it's use in S/MIME or SSL is not necessarily insecure.

bob

Comment 16

[Michael La Guardia]

After reading through the bug, your comments lead me to the conclusion that this
is not essential for shipping?  Is this so?  Marking nsbeta3- on the assumption
it is.  Feel free to clear for reconsideration.

Comment 17

[John Unruh]

Changing QA contact to nitinp

Comment 18

[John Unruh]

Mass reassigning nitinp's bugs to me.

Comment 19

[John Unruh]

Setting to Wontfix. Users can now turn off SSL2 in the Security Manager UI if 
they wish. Also, I see no need to deliberately reduce interoperability, and to 
quote nelsonb on 8/9/00, "Until such time as someone publishes an actual finding 
that these ciphers are shown to be weak, I see no reason to disable them..."

Comment 20

[John Unruh]

Verified wontfix.

Comment 21

[Nicholas Sushkin]

Is there a GUI to disable SMIME RC2?